sibly non-pythonic topic and go read another book or a few hundred so
when it comes up again ...
-Original Message-
From: Python-list On
Behalf Of Thomas Passin
Sent: Saturday, March 4, 2023 5:04 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)
Nope. No consensus.
I’d use self.__class__ . Seems more explicit and direct to me.
From: Python-list on
behalf of Ian Pilcher
Date: Thursday, March 2, 2023 at 4:17 PM
To: python-list@python.org
Subject: Which more Pythonic - self.__class__ or type(self)?
*** Attention: This is an external
t: Saturday, March 4, 2023 1:09 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?
On 3/4/2023 2:47 AM, Peter J. Holzer wrote:
Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that id
it becomes an
exotic addition to Python in a way that loosely melds, or if it becomes the
PYTHONIC way ...
-Original Message-
From: Alan Gauld
Sent: Saturday, March 4, 2023 1:38 PM
To: avi.e.gr...@gmail.com; python-list@python.org
Subject: Re: RE: Which more Pythonic - self.__class__ or t
native language(s).
I am sure some books along these lines have already been written!
Who wants to collaborate?
-Original Message-
From: Python-list On
Behalf Of dn via Python-list
Sent: Saturday, March 4, 2023 1:26 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self
on late and found an
expanding language with way too many ways to do anything and can choose. But
I claim that too is pythonic!
-Original Message-
From: Python-list On
Behalf Of Thomas Passin
Sent: Saturday, March 4, 2023 1:09 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - se
On 2023-03-04 12:38:22 -0500, avi.e.gr...@gmail.com wrote:
> Of course each language has commonly used idioms as C with pointer
> arithmetic and code like *p++=*q++ but my point is that although I live near
> a seaway and from where C originated, I am not aware of words like "c-way"
> or "scenic"
On 04/03/2023 17:38, avi.e.gr...@gmail.com wrote:
>
> Of course each language has commonly used idioms
>
That's the point, the correct term is probably "idiomatic"
rather than "pythonic" but it is a defacto standard that
idiomatic Python has become known as Pythonic. I don't
think that's a prob
On 04/03/2023 20.47, Peter J. Holzer wrote:
On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote:
...
No. Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and libra
On 3/4/2023 2:47 AM, Peter J. Holzer wrote:
Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and library alone, but there is a
cultural element: People writing code in a sp
of seasoned python programmers which they would
prefer, then sometimes there is a more pythonic solution by that definition.
Give the same test to newbies who each came from a different language
background and are just getting started, and I am not sure I care how they
vote!
I suggest that given a d
On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote:
> I do not buy into any concept about something being pythonic or not.
>
> Python has grown too vast and innovated quite a bit, but also borrowed from
> others and vice versa.
>
> There generally is no universally pythonic way nor should
On 4/03/23 7:51 am, avi.e.gr...@gmail.com wrote:
I leave you with the question of the day. Was Voldemort pythonic?
Well, he was fluent in Parseltongue, which is not a good sign.
I hope not, otherwise we'll have to rename Python to "The Language
That Shall Not Be Named" and watch out for horcr
means you should not care
about efficiency! LOL!
I leave you with the question of the day. Was Voldemort pythonic?
Avi
-Original Message-
From: Python-list On
Behalf Of Alan Gauld
Sent: Friday, March 3, 2023 4:43 AM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class
haven't found
>>> anything that talks about which form is considered to be more Pythonic
>>> in those situations where there's no functional difference.
>>
>> I think avoiding dunder methods is generally considered more Pythonic.
Outside of writing dunder
out which form is considered to be more Pythonic
> > in those situations where there's no functional difference.
>
> I think avoiding dunder methods is generally considered more Pythonic.
>
> But in this specific case using isinstance() is almost always
> the better optio
On 02/03/2023 20:54, Ian Pilcher wrote:
> Seems like an FAQ, and I've found a few things on StackOverflow that
> discuss the technical differences in edge cases, but I haven't found
> anything that talks about which form is considered to be more Pythonic
> in those situa
Subject: Re: Which more Pythonic - self.__class__ or type(self)?
On 3/2/2023 5:53 PM, Greg Ewing via Python-list wrote:
> On 3/03/23 9:54 am, Ian Pilcher wrote:
>> I haven't found
>> anything that talks about which form is considered to be more Pythonic
>> in those situations w
On 3/2/2023 5:53 PM, Greg Ewing via Python-list wrote:
On 3/03/23 9:54 am, Ian Pilcher wrote:
I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.
In such cases I'd probably go for t
On 3/03/23 9:54 am, Ian Pilcher wrote:
I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.
In such cases I'd probably go for type(x), because it looks less
ugly.
x.__class__ *might* b
On 3/2/2023 3:54 PM, Ian Pilcher wrote:
Seems like an FAQ, and I've found a few things on StackOverflow that
discuss the technical differences in edge cases, but I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there'
Seems like an FAQ, and I've found a few things on StackOverflow that
discuss the technical differences in edge cases, but I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.
Is ther
On 2019-02-16, Barry wrote:
> On 11 Feb 2019, at 20:00, Felix Lazaro Carbonell wrote:
>
>>> The most pythonic way is to do this:
>>>
>>> def find_monthly_expenses(month=datetime.date.today().month,
>> year=datetime.date.today().year):
>>>...
>
> This has subtle bugs.
> The default is calcul
On 11 Feb 2019, at 20:00, Felix Lazaro Carbonell wrote:
>> The most pythonic way is to do this:
>>
>> def find_monthly_expenses(month=datetime.date.today().month,
> year=datetime.date.today().year):
>>...
This has subtle bugs.
The default is calculated at import time and not at function
The first one is used very often. Less verbose
Le 11 févr. 2019 à 20:41, à 20:41, Felix Lazaro Carbonell
a écrit:
>
>
>Hello to everyone:
>
>Could you please tell me wich way of writing this method is more
>pythonic:
>
>
>
>..
>
>def find_mo
Felix Lazaro Carbonell wrote:
> Hello to everyone:
> Could you please tell me wich way of writing this method is more pythonic:
> def find_monthly_expenses(month=None, year=None):
>
> month = month or datetime.date.today()
> Or it should better be:
>
Grant Edwards wrote:
> On 2019-02-11, Felix Lazaro Carbonell wrote:
>
>> Could you please tell me wich way of writing this method is more
>> pythonic:
>>
>> def find_monthly_expenses(month=None, year=None):
>> month = month or datetime.date.
tations or overrides, etc.
>
>
> -Original Message-
> From: Python-list [mailto:python-list-bounces+david.raymond=
> tomtom@python.org] On Behalf Of Felix Lazaro Carbonell
> Sent: Monday, February 11, 2019 2:30 PM
> To: python-list@python.org
> Subject: more py
On 2/11/2019 2:46 PM, Felix Lazaro Carbonell wrote:
def find_monthly_expenses(month=None, year=None):
month = month or datetime.date.today().month
Or it should better be:
if not month:
month = datetime.date.today().month
As a 20+ year veteran, I would be
lementations or overrides, etc.
-Original Message-
From: Python-list
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of
Felix Lazaro Carbonell
Sent: Monday, February 11, 2019 2:30 PM
To: python-list@python.org
Subject: more pythonic way
Hello to everyone:
Could you
-Mensaje original-
De: Python-list [mailto:python-list-bounces+felix=epepm.cupet...@python.org]
En nombre de Grant Edwards
Enviado el: lunes, 11 de febrero de 2019 02:46 p.m.
Para: python-list@python.org
Asunto: Re: more pythonic way
On 2019-02-11, Felix Lazaro Carbonell wrote
Sorry I meant
..
def find_monthly_expenses(month=None, year=None):
month = month or datetime.date.today().month
..
Or it should better be:
...
if not month:
month = datetime.date.today().month
..
Cheers,
Felix.
--
https://mail.python.org/mailman
On 2019-02-11, Felix Lazaro Carbonell wrote:
> Could you please tell me wich way of writing this method is more pythonic:
>
> def find_monthly_expenses(month=None, year=None):
> month = month or datetime.date.today()
>
> Or it should better be:
>
&
Hello to everyone:
Could you please tell me wich way of writing this method is more pythonic:
..
def find_monthly_expenses(month=None, year=None):
month = month or datetime.date.today()
..
Or it should better be:
...
if not month:
month
On 11 February 2018 at 12:55, D'Arcy Cain wrote:
> On 02/11/18 06:30, Victor Porton wrote:
>> What is more pythonic?
>>
>> 1. Create its subclass PredicateParserWithError and add the additional field
>> on_error to this class.
>>
>> 2. Add on_error fi
On 02/11/18 06:30, Victor Porton wrote:
> What is more pythonic?
>
> 1. Create its subclass PredicateParserWithError and add the additional field
> on_error to this class.
>
> 2. Add on_error field to the base class, setting it to None by default, if
> the class's use
e objects of this class.
What is more pythonic?
1. Create its subclass PredicateParserWithError and add the additional field
on_error to this class.
2. Add on_error field to the base class, setting it to None by default, if
the class's user does not need this field.
--
Victor Porton
rank(hand):
""" Determine the rank of the poker hand. """
rank = int(some_complex_computation(hand))
return rank
In other words, I'm assuming ‘hand_rank’ returns an integer.
> Which of the following is better and more Pythonic ?
Only on
/poker/games/rules/hand-rankings/.
>
> Which of the following is better and more Pythonic ?
>
Your two code segments will do different things.
>
> def poker(hands):
> return max(hands, key=hand_rank)
>
In this case, the "hand_rank" function will take a single ha
et all test-names.
> user-input = tests.testfile (get all test-names from all
> unittest.TestCase derived classes in test.testfile)
> user-input = tests.testfile.Car (get all test-names from the Car
> class)
> user-input = tests.testfile.Cacr.test_stop
>
> and I'm doing it
t-names from the Car
class)
user-input = tests.testfile.Cacr.test_stop
and I'm doing it this the following way and I really think there has
to be more readable, more pythonic and more possibly short way to do
it
import unittest
import sys
import inspect
def get_test_names(full_name,module):
On Dec 3, 10:41 am, Filip Gruszczyński wrote:
> I have just written a very small snippet of code and started thinking,
> which version would be more pythonic. Basically, I am adding a list of
> string to combo box in qt. So, the most obvious way is:
>
> for choice in
Filip Gruszczyński a écrit :
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
choicesBox.addItem(choice
In article ,
Filip GruszczyÅ ski wrote:
>
>for choice in self.__choices:
> choicesBox.addItem(choice)
This is the easiest to read. I'm guessing that this is not inner-loop
stuff that needs to be optimized, so you should favor readability over
performance.
--
-Ed Falk, f...@despam
On 12/4/2009 11:44 AM, Rhodri James wrote:
map(self.__choices, choicesBox.addItem)
or
[choicesBox.addItem(choice) for choice in self.__choices]
Aside from being pythonic or non-pythonic, using map or list
comprehension with a method with side-effect is not the intention of
functional progra
Filip Gruszczyński wrote:
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
choicesBox.addItem(choice)
But I
On Thu, 03 Dec 2009 15:41:56 -, Filip Gruszczyński
wrote:
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
choicesBox.addItem(choice)
But I could also do:
map(self
Hi John,
Thanks for the tips, I will check them out.
--Amr
--
http://mail.python.org/mailman/listinfo/python-list
On May 7, 9:23 am, Amr wrote:
> Hello all,
>
> I've been spending the last few weeks learning Python, and I've just
> started to use it to write a simple BASIC compiler. I'm writing a
> mathematical expression parser and wrote a function that would take a
> string and split it into high level toke
Hello all,
I've been spending the last few weeks learning Python, and I've just
started to use it to write a simple BASIC compiler. I'm writing a
mathematical expression parser and wrote a function that would take a
string and split it into high level tokens.
The code can be found at http://paste
omatically
Pythonic? Are there even more Pythonic alternative codings?
mrkrs = [b for b in block
if b > 127
or b in [ "\r", "\n", "\t" ] ]
I'd worry about "correct" before "Pythonic" ... see my responses to
Dennis in t
On Apr 2, 2:10 am, John Posner wrote:
> Dennis Lee Bieber presented a code snippet with two consecutive statements
> that made me think, "I'd code this differently". So just for fun ... is
> Dennis's original statement or my "_alt" statement more idioma
>> > mrkrs_alt2 = filter(lambda b: b > 127 or b in list("\r\n\t"),
block)
>> >
>>
>> Never tested my 'pythonicity', but I would do:
>>
>> def test(b) : b > 127 or b in r"\r\n\t"
Oops! Clearly,
b in "\r\n\t"
is preferable to ...
b in list("\r\n\t")
You do *not* want to u
On Apr 1, 5:10 pm, John Posner wrote:
> Dennis Lee Bieber presented a code snippet with two consecutive statements
> that made me think, "I'd code this differently". So just for fun ... is
> Dennis's original statement or my "_alt" statement more idioma
Dennis Lee Bieber presented a code snippet with two consecutive statements
that made me think, "I'd code this differently". So just for fun ... is
Dennis's original statement or my "_alt" statement more idiomatically
Pythonic? Are there even more Pythonic alternative
On Dec 6, 12:19 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Fri, 05 Dec 2008 07:44:21 -0800, eric wrote:
> > I like to believe that the less the 'debug pointer' stands in the python
> > code, the fastest the code is (or is potentially)
>
> What's a debug pointer?
>
> Pre-
On Fri, 05 Dec 2008 07:44:21 -0800, eric wrote:
> I like to believe that the less the 'debug pointer' stands in the python
> code, the fastest the code is (or is potentially)
What's a debug pointer?
Pre-mature optimization is the root of evil in programming. Unless you
have actually *measured*
On Dec 5, 3:44 pm, "Mark Tolonen" <[EMAIL PROTECTED]> wrote:
> "eric" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
>
> > def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
> > DOTALL=False, UNICODE=False, VERBOSE=False):
> > vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL
eric wrote:
Hi,
I've got this two pieces of code that works together, and fine
def testit():
for vals in [[i&mask==mask for mask in [1<', flag(*vals)
def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULT
"eric" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
filtered = map( lambda m:m[1],filter( lambda m: m[0]
Hi,
I've got this two pieces of code that works together, and fine
def testit():
for vals in [[i&mask==mask for mask in [1<', flag(*vals)
def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL,
On Oct 10, 9:44 am, Jonathan Fine <[EMAIL PROTECTED]> wrote:
> Hello
>
> I'm using the _winreg module to change Windows registry settings, but
> its rather low level, and I'd prefer to be working with something more
> Pythonic.
>
> Does anyone have any recommen
Jonathan Fine wrote:
Hello
I'm using the _winreg module to change Windows registry settings, but
its rather low level, and I'd prefer to be working with something more
Pythonic.
Does anyone have any recommendations?
Yeah, please implement a nice wrapper and submit
Hello
I'm using the _winreg module to change Windows registry settings, but
its rather low level, and I'd prefer to be working with something more
Pythonic.
Does anyone have any recommendations?
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list
A thousand apologies for my ignorance. I'll try not to get names mixed
up again in the future.
On May 16, 8:42 pm, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> afrobeard <[EMAIL PROTECTED]> writes:
> > Arnaud's code wont work if self.opt1 is None, an empty list, an empty
> > tuple, False, etc, be
afrobeard <[EMAIL PROTECTED]> writes:
> Arnaud's code wont work if self.opt1 is None, an empty list, an empty
> tuple, False, etc, because all these evaluate to false. They wont
> print the internal state of these variables. [Just an informational
> notice, this may be the behavior you expect]
??
Arnaud's code wont work if self.opt1 is None, an empty list, an empty
tuple, False, etc, because all these evaluate to false. They wont
print the internal state of these variables. [Just an informational
notice, this may be the behavior you expect]
Secondly, I'm not sure if you know the variable n
Casey <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have some classes that print variable outputs depending on their
> internal state, like so:
>
> def __str__(self):
> out = []
> if self.opt1: out += ['option 1 is %s' % self.opt1']
> if self.opt2: out += ['option 2 is %s' % self.opt2']
>
Hi,
I have some classes that print variable outputs depending on their
internal state, like so:
def __str__(self):
out = []
if self.opt1: out += ['option 1 is %s' % self.opt1']
if self.opt2: out += ['option 2 is %s' % self.opt2']
return '\n'.join(out)
Is there any way to
Hi,
I have some classes that print variable outputs depending on their internal
state, like so:
def __str__(self):
out = []
if self.opt1: out += ['option 1 is %s' % self.opt1']
if self.opt2: out += ['option 2 is %s' % self.opt2']
return '\n'.join(out)
Is there any way to
On Feb 29, 5:57 pm, Alan Isaac <[EMAIL PROTECTED]> wrote:
> Paul McGuire wrote:
> > In general, whenever you have:
> > someNewList = []
> > for smthg in someSequence:
> > if condition(smthg):
> > someNewList.append( elementDerivedFrom(smthg) )
> > replace it with:
> >
Paul McGuire wrote:
> In general, whenever you have:
> someNewList = []
> for smthg in someSequence:
> if condition(smthg):
> someNewList.append( elementDerivedFrom(smthg) )
> replace it with:
> someNewList = [ elementDerivedFrom(smthg)
>
On Feb 28, 8:58 am, Temoto <[EMAIL PROTECTED]> wrote:
> On 28 ÆÅ×, 15:42, Paul McGuire <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On Feb 28, 5:40 am, Temoto <[EMAIL PROTECTED]> wrote:
>
> > > Hello.
>
> > > There is a Django application, i need to place all its data into
> > > Access mdb file and sen
On 28 фев, 15:42, Paul McGuire <[EMAIL PROTECTED]> wrote:
> On Feb 28, 5:40 am, Temoto <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hello.
>
> > There is a Django application, i need to place all its data into
> > Access mdb file and send it to user.
> > It seems to me that params filling for statement cou
On Feb 28, 5:40 am, Temoto <[EMAIL PROTECTED]> wrote:
> Hello.
>
> There is a Django application, i need to place all its data into
> Access mdb file and send it to user.
> It seems to me that params filling for statement could be expressed in
> a more beautiful way.
> Since i'm very new to Python,
On Feb 28, 4:48 am, 7stud <[EMAIL PROTECTED]> wrote:
>
> It's my understanding that the way you insert arguments into queries
> has to be done in a db specific way.
>
Rather:
It's my understanding that the way you insert arguments into queries
*should* be done in a db specific way.
--
http:/
On Feb 28, 4:40 am, Temoto <[EMAIL PROTECTED]> wrote:
> Hello.
>
> There is a Django application, i need to place all its data into
> Access mdb file and send it to user.
> It seems to me that params filling for statement could be expressed in
> a more beautiful way.
> Since i'm very new to Python,
Hello.
There is a Django application, i need to place all its data into
Access mdb file and send it to user.
It seems to me that params filling for statement could be expressed in
a more beautiful way.
Since i'm very new to Python, i don't feel that, though.
Could you tell your opinion on that sn
[EMAIL PROTECTED] wrote:
> I have a goal function that returns the fitness of a given solution. I
> need to wrap that function with a class or a function to keep track of
> the best solution I encounter. Which of the following would best serve
> my purpose and be the most pythonic?
You could write
On Jan 25, 5:14 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> I have a goal function that returns the fitness of a given solution. I
> need to wrap that function with a class or a function to keep track of
> the best solution I encounter. Which of the following would best serve
> my purpose
Well, regardless of being "pythonic" or not, the first is far more
understandable and therefore more maintainable. Objects were invented
to handle holding state; using a function to hold state is, in my
opinion, doing a language-based cheat. :)
tj
On Jan 24, 2008, at 10:14 PM, [EMAIL PROTE
I have a goal function that returns the fitness of a given solution. I
need to wrap that function with a class or a function to keep track of
the best solution I encounter. Which of the following would best serve
my purpose and be the most pythonic?
class Goal:
def __init__(self, goal):
On 2007-07-30, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Sun, 29 Jul 2007 18:30:22 -0700, CC <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> Yeah, with this I'm not that concerned about Windows. Though, can WinXP
>> still load the ansi.sys driver?
>>
> I'
On Sun, 29 Jul 2007 18:27:25 -0700, CC wrote:
> Marc 'BlackJack' Rintsch wrote:
>> I'd use `string.printable` and remove the "invisible" characters like '\n'
>> or '\t'.
>
> What is `string.printable` ? There is no printable method to strings,
> though I had hoped there would be. I don't yet k
Dennis Lee Bieber wrote:
> On Sun, 29 Jul 2007 12:24:56 -0700, CC <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>>for c in ln:
>> if c in printable: sys.stdout.write(c)
>> else:
>> sys.stdout.write('\x1B[31m.')
>> sys.stdout.write('\x1B[0m')
> Be a
Marc 'BlackJack' Rintsch wrote:
> On Sun, 29 Jul 2007 12:24:56 -0700, CC wrote:
>>The next step consists of printing out the ASCII printable characters.
>>I have devised the following silliness:
>>
>>printable = '
>>[EMAIL PROTECTED]&8*9(0)aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ\
>>`
ln] ) + ' ' )
>
> Either of these produces the desired output:
>
> 00 01 FF 20 34 35 36 08 38 39 61 62 63 64 65 7E
>
> I find the former more readable and simpler. The latter however has a
> slight advantage in not putting a space at the end unless I really want
ntage in not putting a space at the end unless I really want
it. But which is more pythonic?
The next step consists of printing out the ASCII printable characters.
I have devised the following silliness:
printable = '
[EMAIL PROTECTED]&8*9(0)aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTu
On May 10, 2:39 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> 7studwrote:
> >> Is there any documentation for the syntax you used with timeit?
>
> > This is the syntax the docs describe:
> [snip
> > python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
> [snip]
> > Then in the exam
Peter Otten <[EMAIL PROTECTED]> wrote:
> Note the -s before the initialization statement that Alex meant to add but
> didn't. If that is missing
Yep, sorry for erroneously skipping the -s!
Alex
--
http://mail.python.org/mailman/listinfo/python-list
7stud wrote:
>> Is there any documentation for the syntax you used with timeit?
>
> This is the syntax the docs describe:
[snip
> python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
[snip]
> Then in the examples in section 10.10.2
[snip]
> timeit.py 'try:' ' str.__nonzero__' 'exc
> Is there any documentation for the syntax you used with timeit?
This is the syntax the docs describe:
---
Python Reference Library
10.10.1:
When called as a program from the command line, the following form is
used:
python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
---
Then
Stargaming wrote:
> Alex Martelli schrieb:
>> 7stud <[EMAIL PROTECTED]> wrote:
>>...
>>
.append - easy to measure, too:
brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
100 loops, best of 3: 1.31 usec per loop
brain:~ alex$ python -mtimeit '
Alex Martelli schrieb:
> 7stud <[EMAIL PROTECTED]> wrote:
>...
>
>>>.append - easy to measure, too:
>>>
>>>brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
>>>100 loops, best of 3: 1.31 usec per loop
>>>
>>>brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x+=
7stud <[EMAIL PROTECTED]> wrote:
...
> > .append - easy to measure, too:
> >
> > brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
> > 100 loops, best of 3: 1.31 usec per loop
> >
> > brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x+=[n]'
> > 100 loops, be
On May 9, 11:08 am, 7stud <[EMAIL PROTECTED]> wrote:
> On May 8, 11:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
>
>
>
> > alf <[EMAIL PROTECTED]> wrote:
> > > two ways of achieving the same effect
>
> > > l+=[n]
>
> > >
On May 8, 11:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> alf <[EMAIL PROTECTED]> wrote:
> > two ways of achieving the same effect
>
> > l+=[n]
>
> > or
>
> > l.append(n)
>
> > so which is more pythonic/faster?
>
> .append - easy to m
On May 8, 11:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> alf <[EMAIL PROTECTED]> wrote:
> > two ways of achieving the same effect
>
> > l+=[n]
>
> > or
>
> > l.append(n)
>
> > so which is more pythonic/faster?
>
> .append - easy to m
alf <[EMAIL PROTECTED]> wrote:
> two ways of achieving the same effect
>
>
> l+=[n]
>
> or
>
> l.append(n)
>
>
> so which is more pythonic/faster?
.append - easy to measure, too:
brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]
1 - 100 of 162 matches
Mail list logo
