On Fri, 21 Mar 2014 09:40:40 +, Mark Lawrence wrote:
> On 21/03/2014 02:18, Chris Angelico wrote:
>> On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith wrote:
>>> In article <532b8f0d$0$29994$c3e8da3$54964...@news.astraweb.com>,
>>> Steven D'Aprano wrote:
>>>
The rule of three applies here:
On 21/03/2014 02:18, Chris Angelico wrote:
On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith wrote:
In article <532b8f0d$0$29994$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
The rule of three applies here: anything you do in three different places
ought to be managed by a function
On Friday, March 21, 2014 11:38:42 AM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> > Then you're probably not using "sys.stdout.write" but some other file
> > object's write method.
> Correct, sys.stderr.write would have been a more accurate choice.
> > Also, I find it highly unusual tha
Chris Angelico :
> Then you're probably not using "sys.stdout.write" but some other file
> object's write method.
Correct, sys.stderr.write would have been a more accurate choice.
> Also, I find it highly unusual that you never use print in its most
> basic and intended form.
Printing to the st
On Fri, Mar 21, 2014 at 4:49 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> go for the lowest common denominator:
>>
>> print("some single string")
>>
>> which works happily in all versions of Python.
>
> Whenever I have used "print" in my code, it has been with a >>
> redirection.
Then you're
Chris Angelico :
> go for the lowest common denominator:
>
> print("some single string")
>
> which works happily in all versions of Python.
Whenever I have used "print" in my code, it has been with a >>
redirection.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Mar 21, 2014 at 2:16 PM, Steven D'Aprano
wrote:
> I haven't seen scripts broken because "env"
> has moved, but I guess that's only a matter of time.
That usage is extremely common, and isn't it also specified by POSIX?
I think that's about as dependable as you can get.
Course, it does de
On Thu, 20 Mar 2014 21:06:24 -0400, Ned Batchelder wrote:
> In the #python IRC channel, there's a steady flow of people who run
> programs they find online, and they get a syntax error on "print", and
> we say, "Arch?" and they say, "yup".
When you install random programs you find online without
On 3/20/2014 3:07 PM, John Gordon wrote:
There are two ways (at least!) to run a python script:
> On 21/03/2014 8:05 AM, Terry Reedy wrote:
3. [...]
"Our chief weapon is..."
--
https://mail.python.org/mailman/listinfo/python-list
On Friday, March 21, 2014 2:23:25 AM UTC+5:30, Ned Batchelder wrote:
> On 3/20/14 4:42 PM, Marko Rauhamaa wrote:
> > Ned Batchelder :
> >> Plenty of people have adopted a dual-support strategy, with one code
> >> base that supports both Python 2 and Python 3. The six module can help
> >> a great de
On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith wrote:
> In article <532b8f0d$0$29994$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> The rule of three applies here: anything you do in three different places
>> ought to be managed by a function.
>
> I prefer the rule of two :-)
T
On 03/20/2014 05:37 PM, Steven D'Aprano wrote:
In my experience, such as it is, the hard part about writing code that
works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions.
+1000! (yes, that's factorial ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 3/20/14 9:06 PM, Ned Batchelder wrote:
On 3/20/14 8:32 PM, Steven D'Aprano wrote:
On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote:
On 3/20/14 3:07 PM, Eric Jacoboni wrote:
Le 20/03/2014 16:21, Marko Rauhamaa a écrit :
All tutorials will tell you to start it with
#!/usr/bi
On Fri, Mar 21, 2014 at 11:59 AM, Steven D'Aprano
wrote:
> The rule of three applies here: anything you do in three different places
> ought to be managed by a function. Printing a newline at the end of a
> line of output is *incredibly* common. Any language which fails to
> provide a print-with-n
On Fri, Mar 21, 2014 at 11:32 AM, Steven D'Aprano
wrote:
> Perhaps Arch-Linux is guilty of being prematurely Python 3...
>
> I have no idea what "our pain" you are referring to, or who "our" refers
> to. In the three or five years or so since Arch-Linux moved to Python 3
> by default, I don't reca
In article <532b8f0d$0$29994$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> The rule of three applies here: anything you do in three different places
> ought to be managed by a function.
I prefer the rule of two :-)
--
https://mail.python.org/mailman/listinfo/python-list
On 3/20/14 8:32 PM, Steven D'Aprano wrote:
On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote:
On 3/20/14 3:07 PM, Eric Jacoboni wrote:
Le 20/03/2014 16:21, Marko Rauhamaa a écrit :
All tutorials will tell you to start it with
#!/usr/bin/env python
which will start python2 on a
On Thu, 20 Mar 2014 22:50:45 +0200, Marko Rauhamaa wrote:
> Mark Lawrence :
>
>> On 20/03/2014 20:30, Marko Rauhamaa wrote:
>>> I must say, though, that Python3 destroyed "print" forever for me. To
>>> avoid nausea, I write sys.stdout.write() in all Python3 code.
>>
>> Not for me, I was using fro
On Thu, 20 Mar 2014 16:53:25 -0400, Ned Batchelder wrote:
> On 3/20/14 4:42 PM, Marko Rauhamaa wrote:
>> Ned Batchelder :
>>
>>> Plenty of people have adopted a dual-support strategy, with one code
>>> base that supports both Python 2 and Python 3. The six module can help
>>> a great deal with thi
On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote:
> On 3/20/14 3:07 PM, Eric Jacoboni wrote:
>> Le 20/03/2014 16:21, Marko Rauhamaa a écrit :
>>
>>
>>> All tutorials will tell you to start it with
>>>
>>> #!/usr/bin/env python
>>>
>>> which will start python2 on all (?) existing linux
On Thu, 20 Mar 2014 21:28:43 +, notbob wrote:
> On 2014-03-20, Mark H Harris wrote:
>
>> When I call python2 that means python2.7.6 /
>>
>> When I call python3 that means python3.3.4 /
>>
>> I can also call python2.7, which is 2.7.2 /
>>
>> You get the idea. There is no one set rule, becau
On Fri, Mar 21, 2014 at 9:23 AM, Marko Rauhamaa wrote:
> Ned Batchelder :
>> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>>> Well, with proper care, I suppose the same code base could support perl
>>> as well. ;)
>>
>> I'm not sure how to take this comment. I feel like you are mocking my
>> choice.
On Fri, Mar 21, 2014 at 7:08 AM, Marko Rauhamaa wrote:
> Alan Meyer :
>
>> I presume it would still be a good idea to test both python
>> interpreters against any script that you didn't knowingly write with a
>> feature that will only work in one of the two python versions.
>>
>> If it works fine
On 20/03/2014 22:23, Marko Rauhamaa wrote:
Ned Batchelder :
On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
Well, with proper care, I suppose the same code base could support perl
as well. ;)
I'm not sure how to take this comment. I feel like you are mocking my
choice. I wanted to make coverage.py
On Thu, 20 Mar 2014 22:30:57 +0200, Marko Rauhamaa wrote:
> To avoid nausea, I write sys.stdout.write() in all Python3 code.
Now that's funny.
I-know-I-shouldn't-respond-to-obvious-trolling-but-I-can't-help-myself-ly
yrs,
--
Steven D'Aprano
--
https://mail.python.org/mailman/listinfo/python
Ned Batchelder :
> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>> Well, with proper care, I suppose the same code base could support perl
>> as well. ;)
>
> I'm not sure how to take this comment. I feel like you are mocking my
> choice. I wanted to make coverage.py available to as broad an audience
>
On 2014-03-20, Terry Reedy wrote:
> That must be the only one you imported.
So it is. Thank you.
nb
--
https://mail.python.org/mailman/listinfo/python-list
notbob :
> Weeping Chryst on the cross!!. No wonder the latest O'Reilly book,
> Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed
> python is easy. ;)
It's not that bad. There are two principal dialects: python2 and
python3. Take the oldest python version you have to support and wr
On 03/20/2014 11:10 AM, notbob wrote:
> On 2014-03-20, Zachary Ware wrote:
>
>> If you're specifying the interpreter in your command (by calling
>> "python .py", etc), the shebang won't mean anything
>> anyway.
>
> DOH!
>
> I was following you, fine, until that last sentence. Then how should
On 3/20/2014 3:07 PM, John Gordon wrote:
There are two ways (at least!) to run a python script:
1. Execute the python interpreter manually, supplying the python script name
as an arugment, like so:
python myscript.py
python2 otherscript.py
python3 yetanotherscript.py
Thi
On 3/20/2014 1:23 PM, notbob wrote:
What the heck is a .pyc file and how are they created?
.pyc contained compiled bytecode. They are created when, and only when,
you import a module. Imported library files are often big and stable,
so their compiled forms get cached. Top-level scripts are
On 3/20/14 4:28 PM, notbob wrote:
No wonder the latest O'Reilly book, Learning Python, 5th ed,
is 1600 pgs. I coulda swore someone sed python is easy. ;)
nb
Python is easy, but its not simple.
Python is elegant, and full of art, but it has no paucity of constructs,
types, and opportunities
On 20/03/2014 20:50, Marko Rauhamaa wrote:
Mark Lawrence :
On 20/03/2014 20:30, Marko Rauhamaa wrote:
I must say, though, that Python3 destroyed "print" forever for me. To
avoid nausea, I write sys.stdout.write() in all Python3 code.
Not for me, I was using from __future__ import print_funct
On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
Ned Batchelder :
It's an extreme case, but the latest released version of coverage.py
supports Python 2.3 through 3.3 with one code base. To do it, there's
a compatibility layer (akin to six). Then you stay away from features
that aren't available on al
On 2014-03-20, Ned Batchelder wrote:
> On 3/20/14 3:07 PM, Eric Jacoboni wrote:
>> With Arch-Linux, python is python3...
>>
> Yes, and they have been told many times that this was foolish and wrong,
> but it persists, much to our pain.
I've read that 2.7 is the defacto std for python (default
On 2014-03-20, Mark H Harris wrote:
> When I call python2 that means python2.7.6 /
>
> When I call python3 that means python3.3.4 /
>
> I can also call python2.7, which is 2.7.2 /
>
> You get the idea. There is no one set rule, because there are many
> distros (gnu/linux) that use python at va
On Thu, Mar 20, 2014 at 1:59 PM, Marko Rauhamaa wrote:
> Well, with proper care, I suppose the same code base could support perl
> as well. ;)
>
Go even farther; how about C, PHP, and bash? I'm sure if you tried, you
could mix in some Python as well.
http://en.wikipedia.org/wiki/Polyglot_(comput
Ned Batchelder :
> It's an extreme case, but the latest released version of coverage.py
> supports Python 2.3 through 3.3 with one code base. To do it, there's
> a compatibility layer (akin to six). Then you stay away from features
> that aren't available on all versions. In a few places, you migh
Mark Lawrence :
> On 20/03/2014 20:30, Marko Rauhamaa wrote:
>> I must say, though, that Python3 destroyed "print" forever for me. To
>> avoid nausea, I write sys.stdout.write() in all Python3 code.
>
> Not for me, I was using from __future__ import print_function for
> years so got used to typing
On 3/20/14 4:42 PM, Marko Rauhamaa wrote:
Ned Batchelder :
Plenty of people have adopted a dual-support strategy, with one code
base that supports both Python 2 and Python 3. The six module can help
a great deal with this.
I wonder how easy the resulting code is to the eyes and how easy it is
Dan Stromberg :
> Actually, I formerly used /usr/bin/env, but have recently (within the
> last couple of years) stopped.
>
> This is because the env trick doesn't play nicely with top IME. Also,
> it's a trick.
I'm not sure I like it either, but it's a standard idiom in Pythonland.
Marko
--
ht
On 20/03/2014 20:30, Marko Rauhamaa wrote:
Mark Lawrence :
The starter is 2to3 which had been in the standard library for what
seems like an eternity to me.
No problem there. It helps you transition from python2 to python3.
However, python3 is here and you should be able to write genuine pyt
Ned Batchelder :
> Plenty of people have adopted a dual-support strategy, with one code
> base that supports both Python 2 and Python 3. The six module can help
> a great deal with this.
I wonder how easy the resulting code is to the eyes and how easy it is
for the casual maintainer to accidental
On Thu, Mar 20, 2014 at 3:30 PM, Marko Rauhamaa wrote:
> I must say, though, that Python3 destroyed "print" forever for me. To
> avoid nausea, I write sys.stdout.write() in all Python3 code.
To each their own :). I can't stand using 'print' as a statement.
It's a very nice trick to be able to wr
On Thu, Mar 20, 2014 at 8:21 AM, Marko Rauhamaa wrote:
> notbob :
>
>> I've installed python 3.3 on my Slack box, which by default comes with
>> python 2.7. I know how to fire up the different IDLE environments, but
>> how do I differentiate between the scripts? IOW, up till now, I've
>> used .py
Mark Lawrence :
> The starter is 2to3 which had been in the standard library for what
> seems like an eternity to me.
No problem there. It helps you transition from python2 to python3.
However, python3 is here and you should be able to write genuine python3
code with the appropriate bytes and st
On 3/20/14 4:08 PM, Marko Rauhamaa wrote:
Alan Meyer :
I presume it would still be a good idea to test both python
interpreters against any script that you didn't knowingly write with a
feature that will only work in one of the two python versions.
If it works fine in both - and many will, the
On 3/20/14 3:07 PM, Eric Jacoboni wrote:
Le 20/03/2014 16:21, Marko Rauhamaa a écrit :
All tutorials will tell you to start it with
#!/usr/bin/env python
which will start python2 on all (?) existing linux distros, but is
expected to start python3 within the next decade.
With Arch-Linux
On 20/03/2014 20:08, Marko Rauhamaa wrote:
Alan Meyer :
I presume it would still be a good idea to test both python
interpreters against any script that you didn't knowingly write with a
feature that will only work in one of the two python versions.
If it works fine in both - and many will, th
On 3/20/14 2:53 PM, Alan Meyer wrote:
#!/usr/bin/env python
Only use the "python2" or "python3" versions if you really have a reason
to do so.
It gets tricky for distribution (you need docs for your distros, imho)
because #!/usr/bin/env python means different things on different
systems.
Alan Meyer :
> I presume it would still be a good idea to test both python
> interpreters against any script that you didn't knowingly write with a
> feature that will only work in one of the two python versions.
>
> If it works fine in both - and many will, then use:
>
> #!/usr/bin/env pytho
On 3/20/2014 11:21 AM, Marko Rauhamaa wrote:
On a linux box, the initial line of the script indicates the
interpreter:
#!/usr/bin/env python2
for Python 2.x
#!/usr/bin/env python3
for Python 3.x.
All tutorials will tell you to start it with
#!/usr/bin/env python
which will sta
On 3/20/14 12:47 PM, Marko Rauhamaa wrote:
I've seen it done, but at least in those Python 2 days the pyc format
changed between minor releases of Python, so Python itself had to be
shipped with the pyc files.
hi Marko, yeah, I have not done this; being that the concept is contrary
to my princ
Le 20/03/2014 16:21, Marko Rauhamaa a écrit :
> All tutorials will tell you to start it with
>
>#!/usr/bin/env python
>
> which will start python2 on all (?) existing linux distros, but is
> expected to start python3 within the next decade.
With Arch-Linux, python is python3...
--
https:
In notbob writes:
> On 2014-03-20, Zachary Ware wrote:
> > If you're specifying the interpreter in your command (by calling
> > "python .py", etc), the shebang won't mean anything
> > anyway.
> DOH!
> I was following you, fine, until that last sentence. Then how should
> I invoke the scri
On 20/03/2014 15:21, Marko Rauhamaa wrote:
notbob :
I've installed python 3.3 on my Slack box, which by default comes with
python 2.7. I know how to fire up the different IDLE environments, but
how do I differentiate between the scripts? IOW, up till now, I've
used .py on all my 2.7 files. How
On 3/20/14 1:47 PM, Marko Rauhamaa wrote:
Mark H Harris :
If you wanted to you could run your python scripts from the .pyc file
alone. In other words, you may import as long as the .pyc file exists
and the source does not need to be there. Some folks use this (not
recommended) trick to hide or
On 03/20/2014 10:10 AM, notbob wrote:
On 2014-03-20, Zachary Ware wrote:
If you're specifying the interpreter in your command (by calling
"python .py", etc), the shebang won't mean anything
anyway.
DOH!
I was following you, fine, until that last sentence. Then how should
I invoke the script
Mark H Harris :
> If you wanted to you could run your python scripts from the .pyc file
> alone. In other words, you may import as long as the .pyc file exists
> and the source does not need to be there. Some folks use this (not
> recommended) trick to hide or obfuscate their source from their
> u
Chris Angelico :
> Nowadays they'll be pushed away into a separate directory, which makes
> them easier for you to ignore. This is a good thing.
Still, I don't think Python should go and soil my directories without an
explicit permission.
Marko
--
https://mail.python.org/mailman/listinfo/pytho
On 3/20/14 12:23 PM, notbob wrote:
What the heck is a .pyc file and how are they created? Actually, I
can see it's a compiled binary, but I where did it come from?
The world according to me: python is an interpreter (vs compiler) which
converts your source code into tokens and then into a
On Fri, Mar 21, 2014 at 4:10 AM, notbob wrote:
> On 2014-03-20, Zachary Ware wrote:
>
>> If you're specifying the interpreter in your command (by calling
>> "python .py", etc), the shebang won't mean anything
>> anyway.
>
> DOH!
>
> I was following you, fine, until that last sentence. Then how s
On Fri, Mar 21, 2014 at 4:23 AM, notbob wrote:
> On 2014-03-20, Mark H Harris wrote:
>
>> not) there really is no problem. The reason is that the .pyc files
>> created for python2.x are only used by python2.
>
> Lordy, what hath I wrought!? ;)
>
> What the heck is a .pyc file and how are they cr
On 2014-03-20, Mark H Harris wrote:
> not) there really is no problem. The reason is that the .pyc files
> created for python2.x are only used by python2.
Lordy, what hath I wrought!? ;)
What the heck is a .pyc file and how are they created? Actually, I
can see it's a compiled binary, but
On 2014-03-20, Zachary Ware wrote:
> If you're specifying the interpreter in your command (by calling
> "python .py", etc), the shebang won't mean anything
> anyway.
DOH!
I was following you, fine, until that last sentence. Then how should
I invoke the scripts? as your example is exactly
On Thu, Mar 20, 2014 at 11:00 AM, notbob wrote:
> Ahhh! now a shabang I understand. So, I guess the only way, short
> of looking at the actual file, is to include the version in the
> filename. Can I safely assume I can run all 2.7 files w/o a shebang
> (which I have not, so far, and was won
On 3/20/14 9:58 AM, notbob wrote:
I've installed python 3.3 on my Slack box, which by default comes with
python 2.7. I know how to fire up the different IDLE environments,
but how do I differentiate between the scripts?
hi notbob, the two (or more) IDLE environments run very nicely
side-by-s
On 2014-03-20, Marko Rauhamaa wrote:
> That's a bit of a sore spot.
>
> On a linux box, the initial line of the script indicates the
> interpreter:
>
>#!/usr/bin/env python2
>
> for Python 2.x
>
>#!/usr/bin/env python3
>
> for Python 3.x.
>
> All tutorials will tell you to start it with
>
notbob :
> I've installed python 3.3 on my Slack box, which by default comes with
> python 2.7. I know how to fire up the different IDLE environments, but
> how do I differentiate between the scripts? IOW, up till now, I've
> used .py on all my 2.7 files. How do I know not to run a .py in
> python
69 matches
Mail list logo
