Hi,
With awk, I can do something like
$ echo 'hello' |awk '{a[$1]++}END{for(i in a)print i, a[i]}'
That is, a['hello'] was not there but allocated and initialized to
zero upon reference.
With Python, I got b={} b[1] = b[1] +1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 1
That is, I have to initialize b[1] explicitly in the first place.
Personally, I think
a[i]++
in awk is much more elegant than
if i in a: a[i] += 1
else: a[i] = 1
I wonder how the latter is justified in Python.
Thanks,
Weiguang 26 2824
Hmm :)
"b[1]" looks like a List (but you created a Dict)
"b['1'] looks more like a Dict (but this is not what you used).
If lists are your thing: a = [] a.append(1) a
[1] a[0] += 1 a
[2]
If dicts are your thing:
b = {} b['1'] = 1 b
{'1': 1} b['1'] += 1 b
{'1': 2}
Lists are ordered, Dicts are not.
Dict entries accessed with 'string' keys, List entries accessed with a
position integer.
Which feature specifically do you want justification for?
thx
Caleb With Python, I got >>> b={} >>> b[1] = b[1] +1
Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: 1
That is, I have to initialize b[1] explicitly in the first place.
Personally, I think
a[i]++
in awk is much more elegant than
if i in a: a[i] += 1 else: a[i] = 1
I wonder how the latter is justified in Python.
Thanks, Weiguang
On Thu, 25 Nov 2004 18:38:17 +0000 (UTC), wg***@namao.cs.ualberta.ca (Weiguang Shi) wrote: Hi,
With awk, I can do something like $ echo 'hello' |awk '{a[$1]++}END{for(i in a)print i, a[i]}'
That is, a['hello'] was not there but allocated and initialized to zero upon reference.
With Python, I got >>> b={} >>> b[1] = b[1] +1 Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: 1
That is, I have to initialize b[1] explicitly in the first place.
Personally, I think
a[i]++
in awk is much more elegant than
if i in a: a[i] += 1 else: a[i] = 1
I wonder how the latter is justified in Python.
You wrote it, so you have to "justify" it ;-)
While I agree that ++ and -- are handy abbreviations, and creating a key by default
makes for concise notation, a[i]++ means you have to make some narrow assumptions -- i.e.,
that you want to create a zero integer start value. You can certainly make a dict subclass
that behaves that way if you want it: class D(dict):
... def __getitem__(self, i):
... if i not in self: self[i] = 0
... return dict.__getitem__(self, i)
... dink = D() dink
{} dink['a'] +=1 dink
{'a': 1} dink['a'] +=1 dink
{'a': 2} dink['b']
0 dink['b']
0 dink
{'a': 2, 'b': 0}
Otherwise the usual ways are along the lines of
d = {} d.setdefault('hello',[0])[0] += 1 d
{'hello': [1]} d.setdefault('hello',[0])[0] += 1 d
{'hello': [2]}
Or d['hi'] = d.get('hi', 0) + 1 d
{'hi': 1, 'hello': [2]} d['hi'] = d.get('hi', 0) + 1 d
{'hi': 2, 'hello': [2]} d['hi'] = d.get('hi', 0) + 1 d
{'hi': 3, 'hello': [2]}
Or for x in xrange(3):
... try: d['yo'] += 1
... except KeyError: d['yo'] = 1
... print d
...
{'hi': 3, 'hello': [2], 'yo': 1}
{'hi': 3, 'hello': [2], 'yo': 2}
{'hi': 3, 'hello': [2], 'yo': 3}
Regards,
Bengt Richter
Hi,
In article <op**************@news.telkomsa.net>, Caleb Hattingh wrote: ... Dict entries accessed with 'string' keys,
Not necessarily. And doesn't make a difference in my question.
...
Which feature specifically do you want justification for?
Have it your way: string-indexed dictionaries. a={} a['1']+=1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: '1'
a['1'] when it referenced, is detected non-existent but not
automatically initialized so that it exists before adding 1 to its
value.
Weiguang
Hi,
In article <41*****************@news.oz.net>, Bengt Richter wrote: On Thu, 25 Nov 2004 18:38:17 +0000 (UTC), wg***@namao.cs.ualberta.ca (Weiguang Shi) wrote: You wrote it, so you have to "justify" it ;-)
I guess :-)
While I agree that ++ and -- are handy abbreviations, and creating a key by default makes for concise notation, a[i]++ means you have to make some narrow assumptions ...
Right, though generalization can be painful for the uninitiated/newbie.
You can certainly make a dict subclass that behaves that way if you want it: ...
This is nice even for someone hopelessly lazy as me. Otherwise the usual ways are along the lines of ...
I would happily avoid them all.
Thanks a lot,
Weiguang
Hi
I apologise, but I don't actually know what the problem is? If you could
restate it a little, that would help.
I didn't check the code I posted earlier; This below is checked:
***
# Dont use a={}, just start as below
'>>> a['1']=0
'>>> a['1']+=1
'>>> a
{'1': 1}
***
Like I said, I am unsure of what your specific problem is?
Thanks
Caleb
On Thu, 25 Nov 2004 19:27:46 +0000 (UTC), Weiguang Shi
<wg***@namao.cs.ualberta.ca> wrote: Hi,
In article <op**************@news.telkomsa.net>, Caleb Hattingh wrote: ... Dict entries accessed with 'string' keys, Not necessarily. And doesn't make a difference in my question.
...
Which feature specifically do you want justification for? Have it your way: string-indexed dictionaries.
>>> a={} >>> a['1']+=1
Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: '1'
a['1'] when it referenced, is detected non-existent but not automatically initialized so that it exists before adding 1 to its value.
Weiguang
And I haven't even been drinking!
I apologise once more, this is better:
***
# You *must* use a={}, just start as below
'>>> a={}
'>>> a['1']=0
'>>> a['1']+=1
'>>> a
{'1': 1}
***
Like I said, I am unsure of what your specific problem is?
Thanks
Caleb
I don't know awk, so I don't know how your awk statement works.
Even when it comes to the python statements, I'm not sure exactly what the
intentions of design intention were in this case, but I can see at least one
justification. Python being dynamically typed, b[1] can be of any type, so
you have to initialize b[1] to give it a type and only then adding something
to it makes sense. Otherwise, the 'add' operation not being implemented for
all types, 'b[1]+1' may not even be allowed.
You're saying that in awk a['hello'] is initialized to 0. That would not be
justified in python. The type of b[1] is undetermined until initialization
and I don't see why it should be an int by default.
Dan
"Weiguang Shi" <wg***@namao.cs.ualberta.ca> wrote in message
news:slrncqc9kq.hj3.wg***@namao.cs.ualberta.ca... Hi,
With awk, I can do something like $ echo 'hello' |awk '{a[$1]++}END{for(i in a)print i, a[i]}'
That is, a['hello'] was not there but allocated and initialized to zero upon reference.
With Python, I got >>> b={} >>> b[1] = b[1] +1
Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: 1
That is, I have to initialize b[1] explicitly in the first place.
Personally, I think
a[i]++
in awk is much more elegant than
if i in a: a[i] += 1 else: a[i] = 1
I wonder how the latter is justified in Python.
Thanks, Weiguang
In article <lI********************@rogers.com>, Dan Perl wrote: I don't know awk, so I don't know how your awk statement works.
It doesn't hurt to give it a try :-) Even when it comes to the python statements, I'm not sure exactly what the ...
I see your point. You're saying that in awk a['hello'] is initialized to 0.
More than that; I said awk recognizes a['hello']++ as an
arithmetic operation and initializes a['hello'] to 0 and add one to
it. (This is all guess. I didn't implement gawk. But you see my point.)
That would not be justified in python. The type of b[1] is undetermined until initialization and I don't see why it should be an int by default.
In my example, it was b[1]+=1. "+=1" should at least tell Python two
things: this is an add operation and one of the operands is an
integer. Based on these, shouldn't Python be able to insert the pair
"1:0" into a{} before doing the increment?
Weiguang
Hi,
In article <op**************@news.telkomsa.net>, Caleb Hattingh wrote: ... *** # You *must* use a={}, just start as below '>>> a={}
Yeah I know. I can live with that.
'>>> a['1']=0 '>>> a['1']+=1
Right here. You have to say a['1'] = 0 before you can say a['1'] +=1
Python does not do the former for you. That's what I'm asking
justifications for.
Regards,
Weiguang
Weiguang Shi wrote: In article <lI********************@rogers.com>, Dan Perl wrote:That would not be justified in python. The type of b[1] is undetermined until initialization and I don't see why it should be an int by default.
In my example, it was b[1]+=1. "+=1" should at least tell Python two things: this is an add operation and one of the operands is an integer.
Why would it tell Python that? b = {1: 2.5} b[1] += 1 b
{1: 3.5}
So at this point, it can clearly be either an integer or
a float. Doubtless it could also be an object which
overloads the += operator with integer arguments, though
what it might actually do is anyone's guess.
-Peter wg***@namao.cs.ualberta.ca (Weiguang Shi) writes: Hi,
With awk, I can do something like $ echo 'hello' |awk '{a[$1]++}END{for(i in a)print i, a[i]}'
That is, a['hello'] was not there but allocated and initialized to zero upon reference.
With Python, I got >>> b={} >>> b[1] = b[1] +1 Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: 1
That is, I have to initialize b[1] explicitly in the first place.
Personally, I think
a[i]++
in awk is much more elegant than
if i in a: a[i] += 1 else: a[i] = 1
I wonder how the latter is justified in Python.
It isn't :-) a={} a[1] = a.get(1, 0) + 1 a
{1: 1} a[1] = a.get(1, 0) + 1 a
{1: 2}
Regards
Berthold
-- be******@xn--hllmanns-n4a.de / <http://höllmanns.de/> bh***@web.de / <http://starship.python.net/crew/bhoel/> wg***@namao.cs.ualberta.ca (Weiguang Shi) wrote: In article <lI********************@rogers.com>, Dan Perl wrote:I don't know awk, so I don't know how your awk statement works. It doesn't hurt to give it a try :-)
Even when it comes to the python statements, I'm not sure exactly what the ...
I see your point.
You're saying that in awk a['hello'] is initialized to 0.
More than that; I said awk recognizes a['hello']++ as an arithmetic operation and initializes a['hello'] to 0 and add one to it. (This is all guess. I didn't implement gawk. But you see my point.)
That would not be justified in python. The type of b[1] is undetermined until initialization and I don't see why it should be an int by default. In my example, it was b[1]+=1. "+=1" should at least tell Python two things: this is an add operation and one of the operands is an integer. Based on these, shouldn't Python be able to insert the pair "1:0" into a{} before doing the increment?
As Peter has already mentioned, since b[1] doesn't exist until you
assign it, the type of b[1] is ambiguous.
The reason Python doesn't do automatic assignments on unknown access is
due to a few Python 'Zens' import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Specifically:
Explicit is better than implicit.
(you should assign what you want, not expect Python to know what you
want)
Special cases aren't special enough to break the rules.
(incrementing non-existant values in a dictionary shouldn't be any
different from accessing non-existant values)
In the face of ambiguity, refuse the temptation to guess.
(what class/value should the non-existant value initialize to?)
Learn the zens. Any time you have a design question about the Python,
check the zens, then check google, then check here.
- Josiah
Weiguang Shi wrote: With awk, I can do something like $*echo*'hello'*|awk*'{a[$1]++}END{for(i*in*a)print*i,*a[i]}'
That is, a['hello'] was not there but allocated and initialized to zero upon reference.
With Python ... <snip> I have to initialize b[1] explicitly in the first place.
You could use the dictionary's setdefault method, if your value is mutable: b={} for n in xrange(100):
.... b.setdefault('foo', [0])[0] += 1
.... b['foo'][0]
100
Jeffrey
Peter Hansen wrote: In my example, it was b[1]+=1. "+=1" should at least tell Python two things: this is an add operation and one of the operands is an integer.
Why would it tell Python that?
Well, the rhs of 'foo+=1' is always an integer.
Gerrit.
--
Weather in Lulea / Kallax, Sweden 26/11 17:20:
-8.0°C wind 6.7 m/s NW (34 m above NAP)
--
In the councils of government, we must guard against the acquisition of
unwarranted influence, whether sought or unsought, by the
military-industrial complex. The potential for the disastrous rise of
misplaced power exists and will persist.
-Dwight David Eisenhower, January 17, 1961
Just received an email from Batista, Facundo. Below are some quote and
my reply.
On Fri, Nov 26, 2004 at 09:09:46AM -0300, Batista, Facundo wrote: ... >>> a = {} >>> a['1'] = 5 >>> a['1'] *= 2 >>> a['1'] 10 >>> a['1'] = "blah" >>> a['1'] *= 2 >>> a['1'] 'blahblah' >>> a['1'] = ['a', 8] >>> a['1'] *= 2 >>> a['1']
['a', 8, 'a', 8]
The type of the right hand operator does not have nothing to do with the type of the left operand!
You mean in Python, of course. I can see this is going the religious
direction now.
All in all, I've realized when a language generalizes and abstracts,
it loses convenience. Because of this, however powerful other
languages become, awk always has its place as long as the application
is there.
Weiguang
Hi Weiguang
I know how it is when discussion becomes religious, and I want to avoid
that. First, I want to clarify exactly what it is that you are saying:
Would I be correct in saying that your point is that with awk, you can
just do something like (ignore the syntax)
(x not existing yet)
x+=1
And have x = 1, while in Python you have to do
(x not existing yet)
x=0
x+=1
And then have x=1? Is this the question of debate here? One line of
initialisation to specify the type?
IF this is the point you are making, and the awk functionality demostrated
in this particular example is a really significant feature for you in your
specific problem domain, then I must concede that awk is probably right
for you, and you shouldn't waste your time with Python.
Keep well
Caleb
On Fri, 26 Nov 2004 17:53:12 +0000 (UTC), Weiguang Shi
<wg***@namao.cs.ualberta.ca> wrote: You mean in Python, of course. I can see this is going the religious direction now.
All in all, I've realized when a language generalizes and abstracts, it loses convenience. Because of this, however powerful other languages become, awk always has its place as long as the application is there.
Weiguang
Caleb,
In article <op**************@news.telkomsa.net>, Caleb Hattingh wrote: ... And then have x=1? Is this the question of debate here? One line of initialisation to specify the type?
Right. IF this is the point you are making, and the awk functionality demostrated in this particular example is a really significant feature for you in your specific problem domain, then I must concede that awk is probably right for you, and you shouldn't waste your time with Python.
Thanks for the advice. I'll stay with awk and shell for most of my
text processing (simple but, hey, 90% of the time I'm not doing
anything complex) and go Python for binary data processing and larger
projects. BTW, I think learning Python is a good use of my time.
Weiguang
"Caleb Hattingh" <ca****@telkomsa.net> wrote in message
news:op**************@news.telkomsa.net... Hi Weiguang
I know how it is when discussion becomes religious, and I want to avoid that. First, I want to clarify exactly what it is that you are saying:
Would I be correct in saying that your point is that with awk, you can just do something like (ignore the syntax)
(x not existing yet) x+=1
And have x = 1, while in Python you have to do
(x not existing yet) x=0 x+=1
And then have x=1? Is this the question of debate here? One line of initialisation to specify the type?
IF this is the point you are making, and the awk functionality demostrated in this particular example is a really significant feature for you in your specific problem domain, then I must concede that awk is probably right for you, and you shouldn't waste your time with Python.
And just like that, the discussion turned religious. It's hard to assess
someone's tone when it comes in writing, but, Caleb, you sound sarcastic and
belligerent to me.
Yes, 2 lines instead of 1 is an issue. And it is not the only example where
the "explicit is better than implicit" principle shows a downside. However,
addressing Weiguang's statements, I wouldn't say that python is less
convenient than other languages (particularly awk, although I don't know
that language), because I am sure we can find examples where python can
implement something in a simpler way.
Dan
Keep well Caleb
"Dan Perl" <da*****@rogers.com> wrote in message
news:uf********************@rogers.com... "Caleb Hattingh" <ca****@telkomsa.net> wrote in message news:op**************@news.telkomsa.net... IF this is the point you are making, and the awk functionality demostrated in this particular example is a really significant feature for you in your specific problem domain, then I must concede that awk is probably right for you, and you shouldn't waste your time with Python.
And just like that, the discussion turned religious. It's hard to assess someone's tone when it comes in writing, but, Caleb, you sound sarcastic and belligerent to me.
To me, Caleb was being only slightly and possibly sarcastic in the process
of giving friendly good advice to the effect of "better to use Awk and
produce than to beat you head against a wall trying to change a basic
Python design decision.
Almost every design decision has plusses and minuses for designers and
others to weigh. No matter what the designer decides, there will be users
who weigh the factors enough differently to really wish that the decision
was otherwise. In fact, there will probably be another language whose
designer did decide otherwise. And in this case, with regard to the
handling of uninitialized variables, there is.
A Python religion fanatic might have made the opposite suggestion --
something like 'your factor weighting is wrong; see the light and bow to
the superior wisdom of how Python does it'.
Terry J. Reedy
Weiguang Shi wrote: Personally, I think
a[i]++
in awk is much more elegant than
if i in a: a[i] += 1 else: a[i] = 1
As others have pointed out, the type of an uninitialized a[i] is
ambiguous, and that Python doesn't want to try to guess what type to use
based only on the type of the RHS. Depending on what, exactly, the RHS
*is*, there may be multiple likely types for the LHS. The case where
the RHS is an integer is one of the clearer special cases, but Python's
default behavior should be the same regardless of what type the RHS is,
and it doesn't seem safe to assume that the LHS type should always be
equivalent to the RHS type.
But there's another level of ambiguity here. In many cases, throwing an
error for an uninitialized dict item *is* the correct behavior. Suppose
I've got an ascii string representing a DNA gene sequence, and I want to
calculate the relative prevalence of various bases. It's pretty
straightforward to go through and count up how many of each character
there are, using a dict -- but if somehow a letter other than A, G, C,
or T is present, I don't want it to pass silently. It's something very
strange/wrong, and I want to be notified immediately.
Now, in the counting that *you* happen to be doing, assuming that a
default value is desirable works. But that's not universal. And it's
easier to use one of various methods to create a default value (as Bengt
Richter demonstrated) than it is to consistently check that the dict
keys are limited to a particular set of desired keys.
Also, it's not that hard to subclass dict to provide the functionality
that you want. I expect that googling on the c.l.p archives would turn
up more than one recipe for a dict with default values. (There may even
be such a thing in the Python Cookbook.) I know I've seen such things
posted here (though not recently).
Jeff Shannon
Technician/Programmer
Credit International
Jeff Shannon <je**@ccvcorp.com> wrote: Also, it's not that hard to subclass dict to provide the functionality that you want. I expect that googling on the c.l.p archives would turn up more than one recipe for a dict with default values. (There may even be such a thing in the Python Cookbook.) I know I've seen such things posted here (though not recently)
There are several such recipes. The most promising IMHO is Hettinger's
'bag' class (doesn't subclass dict -- uses containment and delegation --
but it deals best with maintaining count-per-item, aka multiset or bag);
it has several bugs as posted, but I've just finished editing it for the
2n edition and it wasn't hard to clear up. I do hope we'll have a
collections.bag in Python 2.5 one day.
Alex
Caleb Hattingh wrote: IF this is the point you are making, and the awk functionality demostrated in this particular example is a really significant feature for you in your specific problem domain, then I must concede that awk is probably right for you, and you shouldn't waste your time with Python.
Unfortunately for the logic, if one finds something like
that to be a "really significant feature ... [in a] specific problem
domain", then with Python you can of course create your own
custom data type which behaves exactly as desired. And in fact
it is likely that there is additional behaviour that could be
added that would make the Python approach to the problem *even
simpler than the awk approach*, but maybe that's getting too
much of a good thing...
Of course, this capability prevents one from whining about how
wonderful a specialized limited-purpose tool is compared to
that waste of space called Python, but if it weren't for people
like that Usenet would have no traffic and we'd all have lives
instead.
-Peter
Peter,
Right :)
I was trying to kill off (with kindness) a thread that just wasn't making
sense. The other respondents gave pretty good technical explanations
regarding the dynamic typing rules, but I suspect the OP's assertion was
just what I described in the simplest terms I could. Which doesn't make
sense as a critical language feature/flaw.
thx
Caleb
On Sat, 27 Nov 2004 12:59:00 -0500, Peter Hansen <pe***@engcorp.com> wrote: Caleb Hattingh wrote: IF this is the point you are making, and the awk functionality demostrated in this particular example is a really significant feature for you in your specific problem domain, then I must concede that awk is probably right for you, and you shouldn't waste your time with Python.
Unfortunately for the logic, if one finds something like that to be a "really significant feature ... [in a] specific problem domain", then with Python you can of course create your own custom data type which behaves exactly as desired. And in fact it is likely that there is additional behaviour that could be added that would make the Python approach to the problem *even simpler than the awk approach*, but maybe that's getting too much of a good thing...
Of course, this capability prevents one from whining about how wonderful a specialized limited-purpose tool is compared to that waste of space called Python, but if it weren't for people like that Usenet would have no traffic and we'd all have lives instead.
-Peter
Hi Dan
I must confess that upon rereading my words, there is some irony there
(but not really sarcasm, is there?). However, I *really* tried to keep
my tone, well, professional. I realise I didn't do a good job and
apologise. I hope that's ok.
Keep well
Caleb
<ca************@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com... Hi Dan
I must confess that upon rereading my words, there is some irony there (but not really sarcasm, is there?). However, I *really* tried to keep my tone, well, professional. I realise I didn't do a good job and apologise. I hope that's ok.
Keep well Caleb
It's water under the bridge. I admire though the fact that you sent this
message.
Dan This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jordi |
last post by:
Hi,
I'm starting to use Python embedded in a C program. I'm using Python
to execute several scripts using as a variables information retrieved
for several multithread "agents" written in C. ...
|
by: none |
last post by:
or is it just me?
I am having a problem with using a dictionary as an attribute of a
class. This happens in python 1.5.2 and 2.2.2 which I am accessing
through pythonwin builds 150 and 148...
|
by: gyro |
last post by:
Hi,
I have a collection of objects that I am currently trying to manage.
Each object is initialized with a dictionary. The dictionaries have the
same keys but may have different values. The...
|
by: Benjamin Scott |
last post by:
Hello.
I attempted to build a compound dictionary:
len(Lst)=1000
len(nuerLst)=250
len(nuestLst)=500
Dict={}
|
by: brianobush |
last post by:
#
# My problem is that I want to create a
# class, but the variables aren't known
# all at once. So, I use a dictionary to
# store the values in temporarily.
# Then when I have a complete set, I...
|
by: Raymond Hettinger |
last post by:
I would like to get everyone's thoughts on two new dictionary methods:
def count(self, value, qty=1):
try:
self += qty
except KeyError:
self = qty
def appendlist(self, key, *values):
try:
|
by: john wright |
last post by:
I have a dictionary oject I created and I want to bind a listbox to it. I
am including the code for the dictionary object.
Here is the error I am getting:
"System.Exception: Complex...
|
by: Almad |
last post by:
Hello,
I discovered this behaviour in dictionary which I find confusing. In
SneakyLang, I've tried to extend dictionary so it visits another class
after something is added:
class...
|
by: Jess |
last post by:
Hello,
I tried several books to find out the details of object
initialization. Unfortunately, I'm still confused by two specific
concepts, namely default-initialization and...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
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
|
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...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |