473,396 Members | 1,770 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

Why and how "there is only one way to do something"?


As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?

Dec 15 '05 #1
44 4137

Tolga wrote:
As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?


if you 'import this', you get a bit of Python Zen... from which I have
taken this line:
*...
There should be one-- and preferably only one --obvious way to do it.
....*
If this is what you are referring to then here is an explanation.

So there is not 'only one way', but rather there should be a way to do
something that is obvious, re easy to find, evident, 'given'...
The quality(ies) looked for here that makes this *really* good is
1- that you don't spend an inordinate amount of time looking for it -
you just go along and use it so your mind can be focussed of what you
need to achieve instead of how you can achieve it.
2- If it's 'obvious', then chances are others will see it and use it
also, so that their code is more understandable by others. For anyone
who has taken care of code of others this can be *really really good*
;-)

Jean-Marc

Dec 15 '05 #2

jmdescha...@gmail.com wrote:
Tolga wrote:
As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?


if you 'import this', you get a bit of Python Zen... from which I have
taken this line:
*...
There should be one-- and preferably only one --obvious way to do it.
...*
If this is what you are referring to then here is an explanation.

So there is not 'only one way', but rather there should be a way to do
something that is obvious, re easy to find, evident, 'given'...
The quality(ies) looked for here that makes this *really* good is
1- that you don't spend an inordinate amount of time looking for it -
you just go along and use it so your mind can be focussed of what you
need to achieve instead of how you can achieve it.
2- If it's 'obvious', then chances are others will see it and use it
also, so that their code is more understandable by others. For anyone
who has taken care of code of others this can be *really really good*
;-)

What I don't quite understand is, if it is "obvious", whether there is
a Zen, people would still code it that way(unless of course they want
to hide it from others or make it difficult to understand on purpose),
there won't be any argument of "which one is the obvious way".
And if there is an argument(or disagreement), which one is the obvious
?

I think it is more like there is a preferred way, by the language
creator and those share his view.

Dec 15 '05 #3
Tolga wrote:
As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?

Perl's credo is actually "There's more than one way to do it", often
abbreviated to TMTOWTDI.

(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".

Clearly as Python is improved (well, develops, anyway :-) new ways to
perform old tasks will become possible. So the obvious way to iterate
over the lines of a text file *used* to be

while 1:
line = f.readline()
if not f:
break
# process the line

whereas now it's

for line in f:
# process the line

As with all credos this should be approached with a large-ish grain of
salt and a pragmatic air. As with all Zen knowledge it's important to
avoid taking the Zen too literally, otherwise it may be necessary to hit
you on the side of the head with a stick to get you moving back towards
enlightenment <0.8 wink>.

We try not to be rude to perlmongers on this group. After all, they have
come much closer to world domination than we have so far, and they can't
help their peculiar penchant for coding in what looks like line noise.
[As you can see it's OK to poke a bit of good-humoured fun at them from
time to time].

Overall Python emphasises two things, readability and comprehensibility,
as primary values. Readability, comprehensibility and a welcoming
approach to newcomers ...

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #4
On 15 Dec 2005 04:32:39 -0800, bo****@gmail.com <bo****@gmail.com> wrote:

jmdescha...@gmail.com wrote:
Tolga wrote:
As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?
if you 'import this', you get a bit of Python Zen... from which I have
taken this line:
*...
There should be one-- and preferably only one --obvious way to do it.
...*
If this is what you are referring to then here is an explanation.

So there is not 'only one way', but rather there should be a way to do
something that is obvious, re easy to find, evident, 'given'...
The quality(ies) looked for here that makes this *really* good is
1- that you don't spend an inordinate amount of time looking for it -
you just go along and use it so your mind can be focussed of what you
need to achieve instead of how you can achieve it.
2- If it's 'obvious', then chances are others will see it and use it
also, so that their code is more understandable by others. For anyone
who has taken care of code of others this can be *really really good*
;-)

What I don't quite understand is, if it is "obvious", whether there is
a Zen, people would still code it that way(unless of course they want
to hide it from others or make it difficult to understand on purpose),
there won't be any argument of "which one is the obvious way".
And if there is an argument(or disagreement), which one is the obvious
?


Many programmers, being clever people, like to do clever things in
order to prove how clever they are. Python programmers are not immune
to this but Perl programmers absolutely revel in it.

As you may be able to tell, I place a very large value on readability
and obviousness and I despise cleverness in code and attempt to stamp
it out when I do it (although, of course, it's hard to see when you're
violating your own rules). As an example, if someone posts on this
list asking how to print the lines of a file, they'll probably get a
bunch of answers with the obvious for loop solution, and a couple from
people being clever with list comprehensions. Even the clever list
comprehension people will usually use the for loop in real code.
Asking the same question on a Perl list will result in 30 different
aswers from 20 different people, and all 30 of those will be used in
real code.

When there is one obvious way to do things, it makes for a large
degree of consistency in code. It improves the readability and
maintainability of Python code in general and flattens the learning
curve. When there is *only* one obvious way to do something, it's even
better.

By and large, programmers are smart people who enjoy solving problems.
That means that doing clever, different ways of doing things is like
candy to programmers and a real temptation. I'm no exception - I
started using perl very early in my programming career and I loved
using all the line noise and cute operators in clever ways. It took
time and some effort to drop that portion of ego from my code and
instead take pride in how mundane, straightforward, and obvious I
could make it, rather than how clever and tricky it was.

And thats why I love the "only one way to do it" thing in Python ;)
I think it is more like there is a preferred way, by the language
creator and those share his view.

--
http://mail.python.org/mailman/listinfo/python-list

Dec 15 '05 #5

Chris Mellon wrote:
On 15 Dec 2005 04:32:39 -0800, bo****@gmail.com <bo****@gmail.com> wrote:

jmdescha...@gmail.com wrote:
Tolga wrote:
> As far as I know, Perl is known as "there are many ways to do
> something" and Python is known as "there is only one way". Could you
> please explain this? How is this possible and is it *really* a good
> concept?

if you 'import this', you get a bit of Python Zen... from which I have
taken this line:
*...
There should be one-- and preferably only one --obvious way to do it.
...*
If this is what you are referring to then here is an explanation.

So there is not 'only one way', but rather there should be a way to do
something that is obvious, re easy to find, evident, 'given'...
The quality(ies) looked for here that makes this *really* good is
1- that you don't spend an inordinate amount of time looking for it -
you just go along and use it so your mind can be focussed of what you
need to achieve instead of how you can achieve it.
2- If it's 'obvious', then chances are others will see it and use it
also, so that their code is more understandable by others. For anyone
who has taken care of code of others this can be *really really good*
;-)

What I don't quite understand is, if it is "obvious", whether there is
a Zen, people would still code it that way(unless of course they want
to hide it from others or make it difficult to understand on purpose),
there won't be any argument of "which one is the obvious way".
And if there is an argument(or disagreement), which one is the obvious
?


Many programmers, being clever people, like to do clever things in
order to prove how clever they are. Python programmers are not immune
to this but Perl programmers absolutely revel in it.

As you may be able to tell, I place a very large value on readability
and obviousness and I despise cleverness in code and attempt to stamp
it out when I do it (although, of course, it's hard to see when you're
violating your own rules). As an example, if someone posts on this
list asking how to print the lines of a file, they'll probably get a
bunch of answers with the obvious for loop solution, and a couple from
people being clever with list comprehensions. Even the clever list
comprehension people will usually use the for loop in real code.
Asking the same question on a Perl list will result in 30 different
aswers from 20 different people, and all 30 of those will be used in
real code.

When there is one obvious way to do things, it makes for a large
degree of consistency in code. It improves the readability and
maintainability of Python code in general and flattens the learning
curve. When there is *only* one obvious way to do something, it's even
better.

By and large, programmers are smart people who enjoy solving problems.
That means that doing clever, different ways of doing things is like
candy to programmers and a real temptation. I'm no exception - I
started using perl very early in my programming career and I loved
using all the line noise and cute operators in clever ways. It took
time and some effort to drop that portion of ego from my code and
instead take pride in how mundane, straightforward, and obvious I
could make it, rather than how clever and tricky it was.

And thats why I love the "only one way to do it" thing in Python ;)

It is perfectly ok to define coding policy within an organisation, for
a project that have more than one developer and things like that. But
if the language allows more than one way to do it, people would try if
that is what they want and they can.

I would say that if "only one way to do it" is the intend, make it into
the language and any other way is simply error. Say if ternary operator
is not the "preferred way", don't have it in the language. If someone
find a way to work around it, change that part of the language to break
their code.

Dec 15 '05 #6
On 15 Dec 2005 05:08:02 -0800, bo****@gmail.com <bo****@gmail.com> wrote:

Chris Mellon wrote:
On 15 Dec 2005 04:32:39 -0800, bo****@gmail.com <bo****@gmail.com> wrote:

jmdescha...@gmail.com wrote:
> Tolga wrote:
> > As far as I know, Perl is known as "there are many ways to do
> > something" and Python is known as "there is only one way". Could you
> > please explain this? How is this possible and is it *really* a good
> > concept?
>
> if you 'import this', you get a bit of Python Zen... from which I have
> taken this line:
> *...
> There should be one-- and preferably only one --obvious way to do it.
> ...*
> If this is what you are referring to then here is an explanation.
>
> So there is not 'only one way', but rather there should be a way todo
> something that is obvious, re easy to find, evident, 'given'...
> The quality(ies) looked for here that makes this *really* good is
> 1- that you don't spend an inordinate amount of time looking for it-
> you just go along and use it so your mind can be focussed of what you
> need to achieve instead of how you can achieve it.
> 2- If it's 'obvious', then chances are others will see it and use it
> also, so that their code is more understandable by others. For anyone
> who has taken care of code of others this can be *really really good*
> ;-)
What I don't quite understand is, if it is "obvious", whether there is
a Zen, people would still code it that way(unless of course they want
to hide it from others or make it difficult to understand on purpose),
there won't be any argument of "which one is the obvious way".
And if there is an argument(or disagreement), which one is the obvious
?

Many programmers, being clever people, like to do clever things in
order to prove how clever they are. Python programmers are not immune
to this but Perl programmers absolutely revel in it.

As you may be able to tell, I place a very large value on readability
and obviousness and I despise cleverness in code and attempt to stamp
it out when I do it (although, of course, it's hard to see when you're
violating your own rules). As an example, if someone posts on this
list asking how to print the lines of a file, they'll probably get a
bunch of answers with the obvious for loop solution, and a couple from
people being clever with list comprehensions. Even the clever list
comprehension people will usually use the for loop in real code.
Asking the same question on a Perl list will result in 30 different
aswers from 20 different people, and all 30 of those will be used in
real code.

When there is one obvious way to do things, it makes for a large
degree of consistency in code. It improves the readability and
maintainability of Python code in general and flattens the learning
curve. When there is *only* one obvious way to do something, it's even
better.

By and large, programmers are smart people who enjoy solving problems.
That means that doing clever, different ways of doing things is like
candy to programmers and a real temptation. I'm no exception - I
started using perl very early in my programming career and I loved
using all the line noise and cute operators in clever ways. It took
time and some effort to drop that portion of ego from my code and
instead take pride in how mundane, straightforward, and obvious I
could make it, rather than how clever and tricky it was.

And thats why I love the "only one way to do it" thing in Python ;)

It is perfectly ok to define coding policy within an organisation, for
a project that have more than one developer and things like that. But
if the language allows more than one way to do it, people would try if
that is what they want and they can.


You can never stop people from being clever. You can only encourage
them to improve themselves. It's like when a teenager finally realizes
that exactly how many studs he has on his jacket really isn't that
important. (Am I dating myself? Do teenagers still put studs on their
jackets?)

I would say that if "only one way to do it" is the intend, make it into
the language and any other way is simply error.
These are called declarative languages and people hate them because
they aren't flexible or extensible. There is a big, big difference
between "only one way to do something, by fiat" and "only one obvious
way to do something".
Say if ternary operator
is not the "preferred way", don't have it in the language. If someone
find a way to work around it, change that part of the language to break
their code.
My understanding of the PEP involved is that the ternary operator is
coming into Python not because of it's merits, but because of the
overly-clever and often broken work-arounds people insist upon using.
It's better to have one clear, obvious way to do something (if/else on
one line, in this case) than it is to have a bunch of often-broken
attempts. You seem very, very interested in portraying anyone who
wants to encourage good style and readability as a language Nazi. I
don't appreciate that. You'll notice that I haven't taken the easy way
out and told you to go away and play with Perl, right?

There are some parallels with writing prose. Mark Twain is a
fantastic, very skilled author by any ones standards but he wrote in a
very straightforward, accessible manner. There's a quote of his to the
effect of "kill your darlings". Write a chapter or whatever, then
re-read it and take out everything you're really proud of, because
those are the bits where you've indulged yourself at the expense of
your reader.

Same philosophy in code. Everyone knows you're smart. You don't have
anything to prove by writing clever code. It's like putting a spoiler
on the back of your Hyundai - you aren't impressing anyone. It is
actually much harder to write simple code, if only because you need to
exert the discipline to resist the impulse to be clever. Python
encourages simplicity, obviousness, and consistency. Those are
*enormous* virtues in every facet of programming. There is never a
benefit to being clever.

Any time you want to write something in any way other than the obvious
way, ask yourself why? Is it more obvious *to you*, which is a good
reason as long as you're only writing code for yourself? Or is it just
to be different, or because you think it'll be faster, or just because
the slickness of it appeals to you?

--
http://mail.python.org/mailman/listinfo/python-list

Dec 15 '05 #7
bo****@gmail.com wrote:
[...]
It is perfectly ok to define coding policy within an organisation, for
a project that have more than one developer and things like that. But
if the language allows more than one way to do it, people would try if
that is what they want and they can.

I would say that if "only one way to do it" is the intend, make it into
the language and any other way is simply error. Say if ternary operator
is not the "preferred way", don't have it in the language. If someone
find a way to work around it, change that part of the language to break
their code.

This would have the unfortunate side effect of only allowing changes to
Python that allowed users to do things which are currently impossible.

Since Python is Turing-complete, this would effectively inhibit all
further changes to the language.

Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #8

Chris Mellon wrote:
You seem very, very interested in portraying anyone who
wants to encourage good style and readability as a language Nazi. I
don't appreciate that. You'll notice that I haven't taken the easy way
out and told you to go away and play with Perl, right? Noop. My stand is that good style and readability is a subjective
matter, to certain extend. The often quoted example of the ternary
operator demonstate that. I have no problem reading it as "this is the
preferred way in python, because we have done a large usability study
which indicate that", but saying it as "obvious" as if it is truth is
just strange to me and yes I would repeatedly pointing that out. You
can tell me to go away but that won't change anything. For most people,
they are not what you described as "trying to be smart" but because of
their background, truly feel that their way is more intuitive(or
obvious). It is just like there are language on this planet that reads
from right to left horizontally, as well as top to bottom, then right
to left. And you are trying to tell them that English way is the "right
way" or the obvious way.

I can't get your meaning of "language Nazi" so using the idiom of
"don't assume", I cannot comment on that part.
Any time you want to write something in any way other than the obvious
way, ask yourself why? Is it more obvious *to you*, which is a good
reason as long as you're only writing code for yourself? Or is it just
to be different, or because you think it'll be faster, or just because
the slickness of it appeals to you?

The point is again, "obvious" is not so obvious sometimes. You seem to
be assuming that anyone that use style different from you is
intentionally doing it and that your style would first come to their
mind but they don't use it, for the sake of proving that they are
smart.
I don't know where you get that idea.

For most of the question I see asking here, they are from another
language background and their obvious way is what they are asking for
that they cannot find in python.

Dec 15 '05 #9
On 15 Dec 2005 05:08:02 -0800
bo****@gmail.com wrote:
I would say that if "only one way to do it" is the intend,
make it into the language and any other way is simply
error. Say if ternary operator is not the "preferred way",
don't have it in the language. If someone find a way to
work around it, change that part of the language to break
their code.


But that is precisely what it does mean -- Python's language
design tries to be "reasonably minimal": there's usually one
fairly easy way to do a task. Unintentionally, there may
well be a half-dozen really hard ways to do it. The point of
telling this to the potential coder is to suggest that "if
it's hard, you're probably doing it the wrong way" and nudge
them into looking at how the language designers have
intended those problems to be solved.

But of course, this is simply a reaction to the Perl motto:
Having a half-dozen more or less equally difficult, equally
documented methods, with no expressed preference, means that
you will find all half-dozen in the wild, which means in
turn that reading and understanding code is six-times harder
to do. Since readability is the primary use of source code,
this translates to the language being pretty close
to six-times harder to use overall.

The problem that has happened with Python is that as the
language is improved, the old "best way" gets replaced with
a new "best way" (hopefully easier). The Python development
team's response to this problem is to specifically
deprecate the old way, and encourage users to adopt the new
way. Generally, the old way does still work so that code
isn't needlessly broken, though there have been exceptions
(such as when the scoping rules were changed).

OTOH, no one can possibly anticipate everything you need to
do, and it is always possible that you have important
requirements for doing things a certain way. We assume that
you are mature enough to know the difference between
"breaking the rules accidentally" and "breaking the rules on
purpose".
--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Dec 15 '05 #10

Steve Holden wrote:
This would have the unfortunate side effect of only allowing changes to
Python that allowed users to do things which are currently impossible.

Since Python is Turing-complete, this would effectively inhibit all
further changes to the language. I don't quote understand the above.

Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement. I
am a left handed and any time I use something that is designed to be
right-handed, I have the same feeling too, luckily there isn't that
much thing in real life.

Dec 15 '05 #11

Terry Hancock wrote:
But that is precisely what it does mean -- Python's language
design tries to be "reasonably minimal": there's usually one
fairly easy way to do a task. Unintentionally, there may
well be a half-dozen really hard ways to do it. The point of
telling this to the potential coder is to suggest that "if
it's hard, you're probably doing it the wrong way" and nudge
them into looking at how the language designers have
intended those problems to be solved.

Um, that is fine. However, what I usually see is like this :

C-programmer learning python :

Hi, where is condition ? true : false

someone prefer the if/else statement type:

Can't you see that the following is much more readable, stupid(well not
the exact word but tone in such a way like words of messy or elegant
etc.)

if condition:
true
else:
false

Dec 15 '05 #12
Steve Holden wrote:
Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...


Interestingly - and somewhat related to this - the other day I was
looking for a do..while or do..until loop in the Python language
reference, thinking that there must be a statement for it, since
semantically they're distinct from while loops. I had a use case that
could have been slightly simplified by such a construct. The fact that
I didn't find one seemed slightly strange at first, coming from a
C/Pascal background, although it did occur to me that I've used Python
for years now and not noticed this lack before.

--
Ben Sizer

Dec 15 '05 #13
Chris Mellon wrote:
[...]
(Am I dating myself? ...)

Do we need to know about your love life here? Are you hermaphroditic? If
not the relationship will never go anywhere.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #14
Yes, a shared preferred way.
And the same is true of many... Think Haskell, OCaml, Lua, Ruby, Lisp,
Smalltalk, Java, C... They all have qualities of some sort, that appeal
to some of us. Not all the same, nor to all of us. It's really a
question of perspective.

In this Python community, one shared preferred way is obviousness, that
we agree or disagree upon, that we argue or ignore as best suits us. It
is not 'the law', it is a wish. For clarity, for communication, for
exchange and for certainly many more reasons.

As a personal experience, I've often been able to use the language
structures, and functions for that matter, out of thin air, because it
seemed *obvious* in the context. But the Help files remain close-by...

Jean-Marc

Dec 15 '05 #15
bo****@gmail.com wrote:
Steve Holden wrote:
This would have the unfortunate side effect of only allowing changes to
Python that allowed users to do things which are currently impossible.

Since Python is Turing-complete, this would effectively inhibit all
further changes to the language.
I don't quote understand the above.

It says that Python is already adequately expressive to allow it to
solve all solvable problems: more briefly, "Python can already do
everything". Hence there is no need to change the language.

Of course I use this as a /reductio ad absurdum/ to try to show you the
falsehood of your position. Sadly I fear this will simply result in
another response which won't move the dialogue forwards.
Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement. I


It seems to me you either don't understand the words "obvious" and
"preferably".
am a left handed and any time I use something that is designed to be
right-handed, I have the same feeling too, luckily there isn't that
much thing in real life.

I believe I have also suggested that the phrases of the Zen aren't to be
taken too literally. You seem to distinguish between "obvious" meaning
"obvious to Steve but not necessarily to me" and "really obvious"
meaning "obvious to both Steve and me". So where does the subjectivity
creep in? And are you going to spend the rest of your life arguing
trivial semantics?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #16
Tolga wrote:
As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?


Yes it is a good concept because you can concentrate on Strategy rather
than Tactics.

Strategy and Tactics

in warfare, related terms referring, respectively, to large-scale and
small-scale planning to achieve military success. Strategy may be
defined as the general scheme of the conduct of a war, tactics as the
planning of means to achieve strategic objectives. Not all theorists of
war make this a primary distinction. In the Chinese and Japanese
traditions processes and paradoxes are emphasized more than categories
(see Sun Tzu ). Karl von Clausewitz , the Prussian military theorist,
who was influenced by Niccolo Machiavelli , described strategy as the
planning of a whole campaign and tactics as the planning of a single
battle. In Clausewitz's theory all military strategy is part of the
larger political pattern, and all the nation's resources are to be
subordinated to the task of attaining the political objective of the
war; to this concerted effort he gave the name "grand strategy."
Antoine H. Jomini , an influential Swiss military theorist and general,
regarded strategy as the art of moving forces to the field of battle
and tactics as the conduct of forces in battle. Another school views
strategy as a means of bringing the enemy to battle and tactics as the
means of defeating him in battle. Some theorists focus on clear sets of
general principles; some wrote books on principles, formations and
maneuvers; and still others dwell on the importance of spirit or other
intangibles.
taken from http://www.encyclopedia.com/html/s1/strategy.asp
Sun Tzu
The Art of War.....stresses the unpredictability of battle, the
importance of deception and surprise, the close relationship between
politics and military policy, and the high costs of war. The futility
of seeking hard and fast rules and the subtle paradoxes of success are
major themes. The best battle, Sun Tzu says, is the battle that is won
without being fought.
from http://www.encyclopedia.com/html/S/SunT1zu.asp
Gerard

Dec 15 '05 #17

Steve Holden wrote:
This would have the unfortunate side effect of only allowing changes to
Python that allowed users to do things which are currently impossible.

Since Python is Turing-complete, this would effectively inhibit all
further changes to the language. I don't quote understand the above.

Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement. I
am a left handed and any time I use something that is designed to be
right-handed, I have the same feeling too, luckily there isn't that
much thing in real life.

Dec 15 '05 #18

Steve Holden wrote:
This would have the unfortunate side effect of only allowing changes to
Python that allowed users to do things which are currently impossible.

Since Python is Turing-complete, this would effectively inhibit all
further changes to the language. I don't quite understand the above.

Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement. I
am a left handed and any time I use something that is designed to be
right-handed, I have the same feeling too, luckily there isn't that
much such thing in real life.

Dec 15 '05 #19

Steve Holden wrote:
It says that Python is already adequately expressive to allow it to
solve all solvable problems: more briefly, "Python can already do
everything". Hence there is no need to change the language.

Of course I use this as a /reductio ad absurdum/ to try to show you the
falsehood of your position. Sadly I fear this will simply result in
another response which won't move the dialogue forwards. Still don't quite understand what you intend to say.
Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...


If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement. I


It seems to me you either don't understand the words "obvious" and
"preferably".

My intepretation of "obvious" is that 99 out of 100 people would
immediately see that "this is the way to do it". I am not sure your
"right meaning" of it.
I believe I have also suggested that the phrases of the Zen aren't to be
taken too literally. You seem to distinguish between "obvious" meaning
"obvious to Steve but not necessarily to me" and "really obvious"
meaning "obvious to both Steve and me". So where does the subjectivity
creep in? And are you going to spend the rest of your life arguing
trivial semantics?

Again, don't quite understand what you what to say.

Dec 15 '05 #20
Ben Sizer wrote:
Steve Holden wrote:

Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

Interestingly - and somewhat related to this - the other day I was
looking for a do..while or do..until loop in the Python language
reference, thinking that there must be a statement for it, since
semantically they're distinct from while loops. I had a use case that
could have been slightly simplified by such a construct. The fact that
I didn't find one seemed slightly strange at first, coming from a
C/Pascal background, although it did occur to me that I've used Python
for years now and not noticed this lack before.

You'll find it's exercised the group frequently from time to time.
Without wishing to stir the whole thing up again, the essence of the
problem is the unnatural fit with Python's suite design.

Would you say

do:
suite
while condition

or what? Basically do ... while and do ... until most naturally put the
test after the loop body (suite), and it's difficult to think of a
consistent and natural syntax for expressing the construct. Not that
this stopped lots of people from coming forward with their personal
favourites ... some suggestions even offered "n and a half" looping
possibilities.

In the end nobody managed to convince Guido that a suitable solution was
readily to hand, so nothing happened.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #21
bo****@gmail.com wrote:
Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...
If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement.

I think comparing "for" and "while" loops in python is problematic.
Although yes a "for" loop could be done with a "while" in python a "for"
loop shouldn't be used for general looping, the "obvious" case for a
"for" loop is to iterate though a list or something similar to that. I
wouldn't typically use "while" loops for that, and although it could be
done, if you were familiar with python using a "for" loop would be the
most obvious. I think it really is obvious in most cases with python.

Although, obvious to whom is a good question. If you don't know the
language very little will be obvious to you, however one who is familiar
with python (rtfm) would know which cases should obviously use "while"
and which cases should obviously use "for"

2cents

--

Carl J. Van Arsdall
cv*********@mvista.com
Build and Release
MontaVista Software

Dec 15 '05 #22
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:

(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".


Actually, I've gotten used to doing

python -c 'import this'
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions. Hire
yourself a competent schmuck." --USENET schmuck (aka Robert Kern)
Dec 15 '05 #23
Aahz wrote:
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:
(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".


Actually, I've gotten used to doing

python -c 'import this'

Which can be built even more easily with

$ python -m this
(no quotes needed btw)

It's usually useful to pipe it through grep too, in order to get only
the piece of zen knowledge you need.
Dec 15 '05 #24

[Steve]
Since Python is Turing-complete


Is there some equivalent of Godwin's Law that we can invoke at this
point? 8-)

--
Richie Hindle
ri****@entrian.com
Dec 15 '05 #25

Carl J. Van Arsdall wrote:
Although, obvious to whom is a good question. If you don't know the
language very little will be obvious to you, however one who is familiar
with python (rtfm) would know which cases should obviously use "while"
and which cases should obviously use "for"

So far, I haven't seen any for/while argument on this thread. So their
usage seems to be obvious to most if not all(which one to choose).

reduce/map/filter obviously is not the obvious way for people from C or
other imperative background, and may not be for those who never program
before.

However, for those who know these functions as well as the for style,
it is no longer so obvious(in the sense which is better/clearer). It
would then become a style choice. It can also be some policy choice,
like because an organisation want to be certain that newly hired
programmer(who would most likely be people from imperative background)
can pick up the program easily, it is better not to use the FP style.

Dec 15 '05 #26
Aahz wrote:
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:
(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".

Actually, I've gotten used to doing

python -c 'import this'


Faster:

python -m this

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #27
On 12/15/05, Steve Holden <st***@holdenweb.com> wrote:
Aahz wrote:
python -c 'import this'


Faster:

python -m this


So, there's two ways to do it. ;-)

--
Cheers,
Simon B,
si***@brunningonline.net,
http://www.brunningonline.net/simon/blog/
Dec 15 '05 #28
bo****@gmail.com wrote:
Chris Mellon wrote:
Any time you want to write something in any way other than the obvious
way, ask yourself why? Is it more obvious *to you*, which is a good
reason as long as you're only writing code for yourself? Or is it just
to be different, or because you think it'll be faster, or just because
the slickness of it appeals to you?


The point is again, "obvious" is not so obvious sometimes. You seem to
be assuming that anyone that use style different from you is
intentionally doing it and that your style would first come to their
mind but they don't use it, for the sake of proving that they are
smart.


My take on it is that "obvious" is intended to be prescriptive, not
descriptive. (Note that in the Zen it is phrased "There *should* be
....".) It describes what Python aspires to, not what it is. If the
currently preferred method is not "the one obvious way", steps should be
taken to make the preferred way "the obvious way" (i.e. the way that you
reach for first, when you want to "do it").

Keep in mind that the Zen was written at a time when there was a certain
amount of "Perl vs. Python deathmatch" feeling in the air. That line in
the Zen was a reaction to Perl's "There's more than one way to do it
(TMTOWTDI)."

Perl took the view that flexibility was a virtue to be praised above all
others, and allows and encourages (or at least used to) different ways
of doing things. I don't think a syntactic construct was excluded from
Perl for the sole reason "well, we already can do that with this
construct ..."

Python, in part due to a backlash to the Perl philosophy, emphasized
clarity and readability. There are *many* constructs which have been
excluded from Python just because they weren't any clearer than what is
already in the language. (Once a language is "Turing complete", anything
you can program a computer to do, you can use that language to do. There
is no guarantee that it's short or pretty, though.) That's what the "one
obvious way" refers to - the clearest, most readable way of expressing
what you want to accomplish.

In this "obviousness", there is (often) little consideration for what
other languages you previously might have used, or might be trying to
drag idioms from. As an absurd analogy, if you were born and grew up in
a country with a crazed totalitarian leader who, under penalty of death,
made you turn around three times while hopping and whistling the
national anthem before you sat down for dinner, it might be "obvious" to
you that one must turn around three times, hopping and whistling before
sitting down for dinner. However, if you move out of that country to,
say, the Netherlands, for instance, you no longer need to
hop-whistle-turn, and your new countrymen will look at you strangely if
you do. That's not to say you can't hop-whistle-turn if the fancy
strikes you, but in any practical setting, people will expect you do the
simple, "obvious" thing -- just sit.
BTW. People who are quick to bring up the Zen (and I'm as guilty as
others at times) should also keep in mind that the Zen is found under
the *humor* section of the Python website. It's not an actual design
document, it's just a surprisingly intuitive description of Python's nature.
Dec 15 '05 #29

bo****@gmail.com wrote:
C-programmer learning python :

Hi, where is condition ? true : false

someone prefer the if/else statement type:

Can't you see that the following is much more readable, stupid(well not
the exact word but tone in such a way like words of messy or elegant
etc.)

if condition:
true
else:
false


Except that the latter isn't an expression, and thus can't be used
inline.

Where you can do: somevar = condition ? true : false

You have to do, instead:
if condition:
somevar = true
else:
somevar = false

It may not seem like a big deal to you, but this approach has a number
of problems, depending on what you're doing. When you're using the
ternary operator you avoid temporary variables, and if you use it a
lot, that's much less that you have to keep track of. It's embeddable
in other arbitrary code, so you can move it around as you need to, or
just keep the morass of side-effects down.

Readability isn't just line-by-line, but a whole work. if/else may work
well most of the time, but sometimes it's ugly, and even though it's
obvious, it doesn't necessarily make your code easier to read.

Dec 15 '05 #30
[Steve Holden, to bonono]
...
I believe I have also suggested that the phrases of the Zen aren't to be
taken too literally.
Heretic.
You seem to distinguish between "obvious" meaning "obvious to Steve
but not necessarily to me" and "really obvious" meaning "obvious to both
Steve and me". So where does the subjectivity creep in?
For those who have ears to hear, it's sufficient to note that:

There should be one-- and preferably only one --obvious way to do it.

is followed by:

Although that way may not be obvious at first unless you're Dutch.
And are you going to spend the rest of your life arguing trivial semantics?


A more interesting question is how many will spend the rest of their
lives responding ;-)

perfect-dutchness-is-a-journey-not-a-destination-ly y'rs - tim
Dec 15 '05 #31
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:
Aahz wrote:
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:

(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".


Actually, I've gotten used to doing

python -c 'import this'


Faster:

python -m this


Only in Python 2.4 and later:

starship:~> python2.3 -m this
Unknown option: -m
usage: python2.3 [option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.

Why, oh why, do so many people on this newsgroup only consider the latest
version "correct"? I've been guilty myself on occasion, but I do try to
label my suggestions with version warnings.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions. Hire
yourself a competent schmuck." --USENET schmuck (aka Robert Kern)
Dec 15 '05 #32
Simon Brunning wrote:
On 12/15/05, Steve Holden <st***@holdenweb.com> wrote:
Aahz wrote:
python -c 'import this'


Faster:

python -m this

So, there's two ways to do it. ;-)

You want a clip round the ear?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #33
On Thu, 15 Dec 2005 14:57:18 +0000 in comp.lang.python, Steve Holden
<st***@holdenweb.com> wrote:

[...]
Would you say

do:
suite
while condition

or what? Basically do ... while and do ... until most naturally put the
Works for me, though I wouldn't cry if the "while" was changed to
"until" to make the difference between this form and the "while" loop
more obvious. I don't think there's a good argument for _both_
do-while and do-until, but one or the other would be useful.

The biggest objection I see is the addition of one or two more
keywords, but I don't recall using "do" or "until" as a name in any of
my programs...
test after the loop body (suite), and it's difficult to think of a
consistent and natural syntax for expressing the construct. Not that
this stopped lots of people from coming forward with their personal
favourites ... some suggestions even offered "n and a half" looping
possibilities.


Syntax is the problem? Specifically the position of the condition
after the loop body? How do you explain the syntax of the new Python
ternary operation, with the test in the middle, even though it
logically has to be done first?

Right now, I tend to write these loops something like

while 1:
do_stuff()
if exit_condition: break

which offends my sense of aesthetics, but it works.

Regards,
-=Dave

--
Change is inevitable, progress is not.
Dec 15 '05 #34
On Thu, 15 Dec 2005 16:28:30 +0100,
Xavier Morel <xa**********@masklinn.net> wrote:
$ python -m this
(no quotes needed btw)
*Three*. *Three* ways to do it: import, -c, -m, and an almost
fanatical devotion to the Pope.
It's usually useful to pipe it through grep too, in order to get only
the piece of zen knowledge you need.


That's just wrong. [throws hands and arms up in [mock] disgust]

Enlightenment does not come in discrete pieces, to be learned one at a
time, to be applied selectively.

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Dec 15 '05 #35
Aahz wrote:
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:
Aahz wrote:
In article <ma***************************************@python. org>,
Steve Holden <st***@holdenweb.com> wrote:

(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".

Actually, I've gotten used to doing

python -c 'import this'


Faster:

python -m this

Only in Python 2.4 and later:

starship:~> python2.3 -m this
Unknown option: -m
usage: python2.3 [option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.

Why, oh why, do so many people on this newsgroup only consider the latest
version "correct"? I've been guilty myself on occasion, but I do try to
label my suggestions with version warnings.


Why, oh why, do people who don't run the latest version assume that a
solution for a more recent version labels their original solution
"incorrect"?

Dammit, the only word in my post apart from the command was "faster".
Not "wronger" or "righter" or even "better". So climb down off that high
horse. Sheesh.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Dec 15 '05 #36
>>>>> "bonono" == bonono <bo****@gmail.com> writes:

bonono> What I don't quite understand is, if it is "obvious",
bonono> whether there is a Zen, people would still code it that
bonono> way(unless of course they want to hide it from others or
bonono> make it difficult to understand on purpose), there won't
bonono> be any argument of "which one is the obvious way". And if
bonono> there is an argument(or disagreement), which one is the
bonono> obvious ?

Python seems to strive for consistency in all levels. The 'obvious
way' is the one with the greatest stylistic cohesion across the rest
of the language.

When you delve into a new realm, as I have lately been investigating
the logging module, consistency helps lower the learning curve; we're
re-cycling as much knowledge as possible.

bonono> I think it is more like there is a preferred way, by the
bonono> language creator and those share his view.

You're right. There is no way to factor out the subjective nature of
what becomes orthodoxy. Guido's taste, while perhaps imperfect, still
stands out. Props.

-Chris
Dec 15 '05 #37
OhmiGod! I posted this message this morning and when I came home, I
said myself "umm, lemme check it" and I cannot believe what I see... 37
threads!

As long as Python is supported by such a hardworking and enthusiastic
community, I'm sure that he (=Python) will become the nightmare of many
other languages.

Thank you all...

Dec 15 '05 #38
bo****@gmail.com writes:
The point is again, "obvious" is not so obvious sometimes.
You keep leaving out the context. We're writing *python*. What's
obvious when you're writing python won't be when you're writing
FORTRAN, or Scheme, or O'Caml, or Eiffel, or .... Generally (not
always, I'll admit), when you're writing python, there's one obvious
way to do something. If not, there's a good chance you're not writing
python, you're writing something else with python syntax.
For most of the question I see asking here, they are from another
language background and their obvious way is what they are asking for
that they cannot find in python.


Back in the dark ages, when computers had entire rooms, if not
buildings, dedicated to them, I worked the support desk at a large
state university. Most people learned FORTRAN as a first language, and
then some of them went on to other languages. The standing observation
was that "You can write FORTRAN in any language." This is because
people would write FORTRAN constructs no matter what language they
were using. If the language had a goto, they'd write:

if not condition: goto after
# if body
after:

If the language didn't have a goto, they'd write:

if not condition:
else:
# if body
And then they'd complain if the grader marked them down for doing
this kind of thing.

People coming from other languages trying to write the obvious way
from that language in python are doing the exact same thing as the
people who wrote the above fragments were doing: writing <fill in the
blank> in python. It's not as obviously wrong because the languages
are more recent than FORTRAN, but it's just as wrong.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Dec 15 '05 #39
On Thu, 15 Dec 2005, Richie Hindle wrote:
[Steve]
Since Python is Turing-complete


Is there some equivalent of Godwin's Law that we can invoke at this
point? 8-)


None that I know of, but perhaps there should be. =) Note that in this
particular thread, we could have invoked the real Godwin's Law already.

Beware of the Turing tar-pit in which everything is possible but nothing
of interest is easy." -- Alan Perlis, "Epigrams on Programming"
Dec 15 '05 #40
On Thu, 15 Dec 2005, Simon Brunning wrote:
On 12/15/05, Steve Holden <st***@holdenweb.com> wrote:
Aahz wrote:
python -c 'import this'


Faster:

python -m this


So, there's two ways to do it. ;-)


Yes, but which way do you do it if you're Dutch?
Dec 15 '05 #41
* Chris Mellon <ar*****@gmail.com> [2005-12-15 06:09]:
(Am I dating myself? Do teenagers still put studs on their jackets?)


No. They put studs in their lips, tongues, eyebrows, navels, and sexual
organs.

Oh, and ears. (How quaint.)
Dec 16 '05 #42
In article <ma***************************************@python. org>,
John Hazen <jo**@hazen.net> wrote:
* Chris Mellon <ar*****@gmail.com> [2005-12-15 06:09]:
(Am I dating myself? Do teenagers still put studs on their jackets?)


No. They put studs in their lips, tongues, eyebrows, navels, and sexual
organs.

Oh, and ears. (How quaint.)


I don't believe I've ever seen anybody with a stud in their eyebrow.
Plenty of rings, but not studs. Maybe I just don't hang out in the right
places?
Dec 16 '05 #43

Tolga wrote:
As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?


Do you know about the existence of god, just or scientific truth? Of
course not. All this is highly imaginary and transendental. It's always
outside of the system allthough the believe that it is immanent may be
part of it's promotion and is always an essential part of a working
belief system that is added to reality. So while it is actually
impossible to have any evidence a community may strive for it's
presence and this is their basic principle. A "pythonic" solution to a
programming problem in Python is both impossible and unverifiable, but
also inevitable and a necessary part of it's reflection. It wouldn't be
a Zen aspect if there is not the language itself is speeking. In the
end everything is open to interpretation, but interpretation is itself
a "glue code".

But why unique? I don't know. Maybe because there are only three
numbers: one, two and many. Perl is many. Duality is mysterious. One is
simple.

Kay

Dec 16 '05 #44
bo****@gmail.com said unto the world upon 2005-12-15 07:50:
obvious). It is just like there are language on this planet that reads
from right to left horizontally, as well as top to bottom, then right
to left. And you are trying to tell them that English way is the "right
way" or the obvious way.


..English write to way obvious the is right to left that just, No

Dec 16 '05 #45

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

51
by: Noam Raphael | last post by:
Hello, I thought about a new Python feature. Please tell me what you think about it. Say you want to write a base class with some unimplemented methods, that subclasses must implement (or...
6
by: Mason A. Clark | last post by:
LAST WORD(s): 1. MSIE6 and Firefox will go to the top of the page on command <a href="#top">go upsy</a> even if there is NO name="top" or id="top" They know what a "top" is :-) Opera...
11
by: Paul D.Smith | last post by:
Can Python create a variable "on-the-fly". For example I would like something like... make_variable('OSCAR', 'the grouch'); print OSCAR; ....to output... the grouch
3
by: Petr Prikryl | last post by:
Hi all, My question is: How do you tackle with mixing Unicode and non-Unicode parts of your application? Context: ======== The PEP 3000 says "Make all strings be Unicode, and have a...
1
by: Mark E. Hamilton | last post by:
Sorry, I probably should have re-stated the problem: We're using Python 2.3.5 on AIX 5.2, and get the follow error messages from some of our code. I haven't yet tracked down exactly where it's...
10
by: schears | last post by:
Why? Running on windows 2000 with all updates, 2G Memory, 117G Hard Drive space available. This was not an issue until I added some code to two of my c files. Any suggestions? Thanks
4
by: Mike Cooper | last post by:
There is something about inherited classes I evidently don't know... I wrote the following class: Class Class1 inherits System.Windows.Forms.DataGridTextBoxColumn End Class There is...
10
by: RDI | last post by:
What's it mean? My prog runs fine. Then as soon as I press ok or cancel, the following is what's in the output area of the debugger. TIA -- RDI (remove the exclamation from the email...
2
by: John Nagle | last post by:
For some reason, Python's parser for "robots.txt" files doesn't like Wikipedia's "robots.txt" file: False The Wikipedia robots.txt file passes robots.txt validation, and it doesn't disallow...
56
by: Adem | last post by:
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" The C++ Standard (ISO/IEC 14882, Second edition, 2003-10-15) says under...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.