This has to do with class variables and instances variables.
Given the following:
<code>
class _class:
var = 0
#rest of the class
instance_b = _class()
_class.var=5
print instance_b.var # -> 5
print _class.var # -> 5
</code>
Initially this seems to make sense, note the difference between to last
two lines, one is refering to the class variable 'var' via the class
while the other refers to it via an instance.
However if one attempts the following:
<code>
instance_b.var = 1000 # -> _class.var = 5
_class.var = 9999 # -> _class.var = 9999
</code>
An obvious error occurs. When attempting to assign the class variable
via the instance it instead creates a new entry in that instance's
__dict__ and gives it the value. While this is allowed because of
pythons ability to dynamically add attributes to a instance however it
seems incorrect to have different behavior for different operations.
There are two possible fixes, either by prohibiting instance variables
with the same name as class variables, which would allow any reference
to an instance of the class assign/read the value of the variable. Or
to only allow class variables to be accessed via the class name itself.
Many thanks to elpargo and coke. elpargo assisted in fleshing out the
best way to present this.
perhaps this was intended, i was just wondering if anyone else had
noticed it, and if so what form would you consider to be 'proper'
either referring to class variables via the class itself or via
instances of that class. Any response would be greatly appreciated.
Graham
Nov 3 '05
166 8669
Op 2005-11-04, Christopher Subich schreef <cs************ ****@spam.subic h.block.com>: Antoon Pardon wrote: Well I wonder. Would the following code be considered a name binding operation:
b.a = 5 Try it, it's not.
Python 2.2.3 (#1, Nov 12 2004, 13:02:04) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)] on linux2 Type "help", "copyright" , "credits" or "license" for more information. a Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'a' is not defined b = object() b.a
Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'object' object has no attribute 'a'
Once it's attached to an object, it's an attribute, not a base name.
So? It is still a name and it gets bound to an object. Sure the name
is bound within a specific namespace but that is IMO a detail.
unified for Py3k, but in cases like this the distinction is important.
But part of this dicussion is about the sanity of making these kind
of distinctions. Since they apparantly plan to get rid of them in
Py3k, I guess I'm not the only one questioning that.
--
Antoon Pardon
Op 2005-11-04, Magnus Lycka schreef <ly***@carmen.s e>: Antoon Pardon wrote: > I have looked and didn't find it in the language reference.
This is what I have found:
An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. It's just a little further down. I'll post the quote once more (but this is the last time ;^):
I appreciate you quoting the documentation. But I would appreciate
a URL even more. It isn't necessary now any more but it would have
been usefull the first time you quoted this material.
"""For targets which are attribute references, the initial value is retrieved with a getattr() and the result is assigned with a setattr(). Notice that the two methods do not necessarily refer to the same variable. When getattr() refers to a class variable, setattr() still writes to an instance variable. For example:
class A: x = 3 # class variable a = A() a.x += 1 # writes a.x as 4 leaving A.x as 3"""
I'd say it's documented...
Well then I guess they have documented awkward behaviour. That doesn't change the fact that the current behaviour is on occasions awkward or whatever you want to call it.
I fear that this has to do with the way reality works. Perhaps it's due to Gödel's incompleteness theorems... :)
Sure, Python has evolved and grown for about 15 years, and backward compatibility has always been an issue, but the management and development of Python is dynamic and fairly open-minded. If there had been an obvious way to change this in a way that solved more problems than it caused, I suspect that change would have happened already.
Fine I can live with that.
--
Antoon Pardon
Op 2005-11-04, Christopher Subich schreef <cs************ ****@spam.subic h.block.com>: Antoon Pardon wrote: Well maybe because as far as I understand the same kind of logic can be applied to something like
lst[f()] += foo
In order to decide that this should be equivallent to
lst[f()] = lst[f()] + foo.
But that isn't the case. Because, surprisingly enough, Python tends to evaluate expressions only once each time they're invoked.
Well but once can consider b.a as an expression too. An expression
that gets evaluated twice in case of
b.a += 2
In this case, [] is being used to get an item and set an item -- therefore, it /has/ to be invoked twice -- once for __getitem__, and once for __setitem__.
But we are here questioning language design. One could question a design
where it is necessary to invoke the [] operator twice, even when it
is only mentioned once in the code.
Likewises, lst appears once, and it is used once -- the name gets looked up once (which leads to a += 1 problems if a is in an outer scope).
f() also appears once -- so to evaluate it more than one time is odd, at best.
No more or less than "[]" or "." is to be invoked twice.
--
Antoon Pardon
Op 2005-11-04, Steven D'Aprano schreef <st***@REMOVETH IScyber.com.au> : On Fri, 04 Nov 2005 08:08:42 +0000, Antoon Pardon wrote:
One other way, to implement the += and likewise operators would be something like the following.
Assume a getnsattr, which would work like getattr, but would also return the namespace where the name was found. The implementation of b.a += 2 could then be something like:
ns, t = getnsattr(b, 'a') t = t + 2 setattr(ns, 'a')
I'm not arguing that this is how it should be implemented. Just showing the implication doesn't follow.
Follow the logical implications of this proposed behaviour.
class Game: current_level = 1 # by default, games start at level one
def advance(self): self.current_le vel += 1
py> antoon_game = Game() py> steve_game = Game() py> steve_game.adva nce() py> steve_game.adva nce() py> print steve_game.leve l 3 py> print antoon_game.lev el
What will it print?
Hint: your scheme means that class attributes mask instance attributes.
So? This proposal was not meant to replace the current behaviour.
It was meant to contradict your assertion that some particular
behaviour implied mutable numbers.
My proposal was an example that showed the particular behaviour and
didn't require mutable numbers, so it showed your assertion false.
--
Antoon Pardon
Op 2005-11-04, Steven D'Aprano schreef <st***@REMOVETH IScyber.com.au> : On Fri, 04 Nov 2005 10:48:54 +0000, Antoon Pardon wrote:
Please explain why this is illegal.
x = 1 def f(): x += 1
Because names in function namespaces don't have inheritance.
Your quibling about words. This certainly works.
x = 1
def f():
a = x + 1
So you could say that function namespaces do inherit from
outer scopes.
Whether you want to name it inheritance or not, is not the
issue.
--
Antoon Pardon
Op 2005-11-04, Steven D'Aprano schreef <st***@REMOVETH IScyber.com.au> : On Fri, 04 Nov 2005 09:07:38 +0000, Antoon Pardon wrote:
Now the b.a on the right hand side refers to A.a the first time through the loop but not the next times. I don't think it is sane that which object is refered to depends on how many times you already went through the loop. [snip] Look at that: the object which is referred to depends on how many times you've already been through the loop. How nuts is that?
It is each time the 'x' from the same name space. In the code above the 'a' is not each time from the same namespace.
I also think you new very well what I meant.
I'm supposed to be a mindreader now? After you've spent multiple posts ranting that, quote, "I don't think it is sane that which object is refered to depends on how many times you already went through the loop", I'm supposed to magically read your mind and know that you don't actually object to what you say you object to, but to something completely different?
No I meant object when I wrote object. But it is not about the object,
it is about the "being refered to". And how do you refer to objects,
by names in namespace or variables.
--
Antoon Pardon
Op 2005-11-06, Steve Holden schreef <st***@holdenwe b.com>: Steven D'Aprano wrote: [...] But I can't understand the position of folks who want inheritance but don't want the behaviour that Python currently exhibits. instance.attrib ute sometimes reading from the class attribute is a feature of inheritance; instance.attrib ute always writing to the instance is a feature of OOP; instance.attrib ute sometimes writing to the instance and sometimes writing to the class would be, in my opinion, not just a wart but a full-blown misfeature.
I ask and I ask and I ask for some use of this proposed behaviour, and nobody is either willing or able to tell me where how or why it would be useful. What should I conclude from this?
You should conclude that some readers of this group are happier designing languages with theoretical purity completely disconnected from users' needs. But of course we pragmatists know that practicality beats purity :-)
But explicit is better than implicit.
--
Antoon Pardon
Op 2005-11-05, Steven D'Aprano schreef <st***@REMOVETH IScyber.com.au> : On Fri, 04 Nov 2005 12:10:11 +0000, Antoon Pardon wrote:
There are good usage cases for the current inheritance behaviour. I asked before what usage case or cases you have for your desired behaviour, and you haven't answered. Perhaps you missed the question? Perhaps you haven't had a chance to reply yet? Or perhaps you have no usage case for the behaviour you want. There are good use cases for a lot of things python doesn't provide. There are good use cases for writable closures, but python doesn't provide it, shrug, I can live with that. Use cases is a red herring here.
Is that a round-about way of saying that you really have no idea of whether, how or when your proposed behaviour would be useful?
I am not proposing specific behaviour. Because if I do, you will
just try to argue how much worst my proposed behaviour is.
Whether or not I can come up with a better proposal is irrelevant
to how sane the current behaviour is.
Personally, I think that when you are proposing a major change to a language that would break the way inheritance works, there should be more benefits to the new way than the old way.
How many times do I have to repeat myself. I'm not proposing a change
to the language. Some things are a matter of taste: should CPython prefer <> or != for not equal? Some things are a matter of objective fact: should CPython use a byte-code compiler and virtual machine, or a 1970s style interpreter that interprets the source code directly?
The behaviour you are calling "insane" is partly a matter of taste, but it is mostly a matter of objective fact. I believe that the standard model for inheritance that you call insane is rational because it is useful in far more potential and actual pieces of code than the behaviour you prefer -- and the designers of (almost?) all OO languages seem to agree with me.
I didn't call the model for inheritance insane.
Antoon, I've been pedanted at by experts, and you ain't one. The behaviour which you repeatedly described as not sane implements the model for inheritance. The fact that you never explicitly said "the standard OO model of inheritance" cuts no ice with me, not when you've written multiple posts saying that the behaviour of that standard inheritance model is not sane.
I haven't written that once. You may think that you can imply it from
what I wrote, but then that is your inferance and not my words. The standard behaviour makes it easy for code to do the right thing in more cases, without the developer taking any special steps, and in the few cases where it doesn't do the right thing (e.g. when the behaviour you want is for all instances to share state) it is easy to work around. By contrast, the behaviour you want seems to be of very limited usefulness, and it makes it difficult to do the expected thing in almost all cases, and work-arounds are complex and easy to get wrong.
Please don't make this about what I *want*. I don't want anything. I just noted that one and the same reference can be processed multiple times by the python machinery, resulting in that same reference referencing differnt variables at the same time and stated that that was unsane behaviour.
"Unsane" now?
Heaven forbid that I should criticise people for inventing new words, but how precisely is unsane different from insane? In standard English, something which is not sane is insane.
Well maybe English works differently from dutch, but I thought there
were a whole lot of gradation between sane and insane. And not being
sane IMO just means not being at one end of the extreme while being
insane meant to be at the other end of the extreme.
So when something doesn't make complete sense, instead of it making
no sense at all, I would think that wording it as unsane instead of
insane resembles best what I intended to mean.
If you're just trolling, you've done a great job of it because you fooled me well and good. But if you are serious in your criticism about the behaviour, then stop mucking about and tell us what the behaviour should be. Otherwise your criticism isn't going to have any practical effect on the language at all.
I wasn't trolling. I just threw in an off hand remark. That you got so
heated up about that remark is not my responsibility. I'm not trolling
because I'm willing to defend my remark and I don't intend to get
people to get heated up about it. I just don't hold back because
people may get heated up about it.
If you are serious about wanting the behaviour changed, and not just whining, then somebody has to come up with an alternative behaviour that is better.
If I would be whining I would want the behaviour changed. I would just
keep complaining about it until someone else would have changed it.
Sure I would prefer it changed, but it is not that I *want* it to
change. I'll happily continue with python if it doesn't change.
Maybe when someone mentions something negative about python,
you shouldn't translate that into someone demanding a change
in python.
If not you, then who? Most of the folks who have commented on this thread seem to like the existing behaviour.
Well fine, in that case it won't even change if I do come up with
an alternative proposal. So why should I bother?
--
Antoon Pardon
First of all, I've still not heard any sensible suggestions
about a saner behaviour for augmented assignment or for the
way Python searches the class scope after the instance scope.
What do you suggest?
Today, x += n acts just as x = x + n if x is immutable.
Do you suggest that this should change?
Today, instance.var will look for var in the class
scope if it didn't find it in the instance scope. Do
you propose to change this?
Or, do you propose that we should have some second order
effect that makes the combination of instance.var += n
work in such a way that these features are no longer
orthogonal?
Paul Rubin wrote: Steven D'Aprano <st***@REMOVETH IScyber.com.au> writes:
A basic usage case:
class Paper: size = A4 def __init__(self, contents): # it makes no sense to have class contents, # so contents go straight into the instance self.contents = contents
So add:
self.size = Paper.size
and you've removed the weirdness. What do you gain here by inheriting?
class LetterPaper(Pap er):
size = Letter
class LegalPaper(Pape r):
size = Legal
This is what you gain. Subclassing it extremely simple, if all
you want is that the subclass differs in data. You could also
have __init__ pick up the class variable and set an instance
variable, but why make things difficult if it's trivial now?
Considering how __init__ works in Python class hierachies,
where you need to manually call __init__ in ancestor classes
if you've overridden them, the fact that a simple self.size
picks up a class variable is particularly useful if you use
MI. For instance I could imagine a FirstPageMixin class in
this case, and a FancyFirstPageM ixin that subclasses that.
There, we might want to pick up certain margin values or
other positions etc.
The spirit of Python is to make it easy to do things right,
not make it difficult to make mistakes. If you want a language
that tries to prevent you from making mistakes, use Ada.
When developing code in a dynamic language such as Python,
it's really important to have a decent set of automated tests.
If you have, you'll hopefully notice bugs like these. Making
changes in the language that forces you to write more code
will in general not reduce the total number of bugs, but
rather increase them.
I've been involved with high reliability design long enough to
know the problems involved fairly well. I mainly worked with
electronic design then, but the problem is the same: The more
safety gadgets you add, the more stuff you have that can break.
The details are a bit difference, but in principle the problem
is the same.
Ever wondered why Russian and Chinese rocket launchers have a
better reliability than the American? Simply put, they're simpler.
Antoon Pardon wrote: Op 2005-11-05, Steven D'Aprano schreef <st***@REMOVETH IScyber.com.au> :
On Fri, 04 Nov 2005 12:10:11 +0000, Antoon Pardon wrote:
There are good usage cases for the current inheritance behaviour. I asked before what usage case or cases you have for your desired behaviour, and you haven't answered. Perhaps you missed the question? Perhaps you haven't had a chance to reply yet? Or perhaps you have no usage case for the behaviour you want.
There are good use cases for a lot of things python doesn't provide. There are good use cases for writable closures, but python doesn't provide it, shrug, I can live with that. Use cases is a red herring here. Is that a round-about way of saying that you really have no idea of whether, how or when your proposed behaviour would be useful?
I am not proposing specific behaviour. Because if I do, you will just try to argue how much worst my proposed behaviour is.
Whether or not I can come up with a better proposal is irrelevant to how sane the current behaviour is.
If you can't provide a superior alternative then you have little right
to be questioning the present behavior. Honestly, you are like a child
with a whistle who keeps blowing the whistle to the annoyance of all
around it simply because it likes being able to make the noise, and
causing the annoyance.Personally, I think that when you are proposing a major change to a language that would break the way inheritance works, there should be more benefits to the new way than the old way.
How many times do I have to repeat myself. I'm not proposing a change to the language.
So you have a clear impression that Python's current behavior is
unsatisfactory enough to be called "unsane" which, when challenged, you
insist simply means not at the extreme end of some imaginary sanity
scale you have constructed for the purpose if bending English to your
will. And you refuse to propose anything further towards the sane end of
the scale because people will try to argue that your proposal would be
worse than the existing behavior. Good grief, I though I was dealing
with an adult here, but I must be mistaken.Some things are a matter of taste: should CPython prefer <> or != for not equal? Some things are a matter of objective fact: should CPython use a byte-code compiler and virtual machine, or a 1970s style interpreter that interpret s the source code directly?
The behaviour you are calling "insane" is partly a matter of taste, but it is mostly a matter of objective fact. I believe that the standard model for inheritance that you call insane is rational because it is useful in far more potential and actual pieces of code than the behaviour you prefer -- and the designers of (almost?) all OO languages seem to agree with me.
I didn't call the model for inheritance insane.
Well you are repeatedly call one aspect of the Python inheritance model
insane. You appear to feel that repetition of an argument will make it
more true, which is sadly not the case. Antoon, I've been pedanted at by experts, and you ain't one. The behaviour which you repeatedly described as not sane implements the model for inheritance . The fact that you never explicitly said "the standard OO model of inheritance" cuts no ice with me, not when you've written multiple posts saying that the behaviour of that standard inheritance model is not sane.
I haven't written that once. You may think that you can imply it from what I wrote, but then that is your inferance and not my words.
Nonsense.The standard behaviour makes it easy for code to do the right thing in more cases, without the developer taking any special steps, and in the few cases where it doesn't do the right thing (e.g. when the behaviour you want is for all instances to share state) it is easy to work around. By contrast, the behaviour you want seems to be of very limited usefulnes s, and it makes it difficult to do the expected thing in almost all cases, and work-arounds are complex and easy to get wrong.
Please don't make this about what I *want*. I don't want anything. I just noted that one and the same reference can be processed multiple times by the python machinery, resulting in that same reference referencin g differnt variables at the same time and stated that that was unsane behaviour.
But you clearly don't perceive this as being related to Python's
inheritance mechanism, presumably because you aren't prepared to accept
that an instance inherits names from its class just like a class
inherits names from its superclass.
"Unsane" now?
Heaven forbid that I should criticise people for inventing new words, but how precisely is unsane different from insane? In standard English, something which is not sane is insane.
Well maybe English works differently from dutch, but I thought there were a whole lot of gradation between sane and insane. And not being sane IMO just means not being at one end of the extreme while being insane meant to be at the other end of the extreme.
So when something doesn't make complete sense, instead of it making no sense at all, I would think that wording it as unsane instead of insane resembles best what I intended to mean.
Ah, so Python isn't the only language you find insufficiently
expressive. I normally give some leeway to those whose first language
isn't English, but this particular bloody-mindedness has gone on long
enough. I'd call your behavior imhelpful here.
So, are we talking about 0.1% insane, 10% insane or 90% insane. For
someone who is so pedantic you are being insanely vague here. You can
hardly blame people for concluding you just like the sound of your own
voice (metaphorically speaking).If you're just trolling, you've done a great job of it because you fooled me well and good. But if you are serious in your criticism about the behaviour, then stop mucking about and tell us what the behaviour should be. Otherwise your criticism isn't going to have any practical effect on the language at all.
I wasn't trolling. I just threw in an off hand remark. That you got so heated up about that remark is not my responsibility. I'm not trolling because I'm willing to defend my remark and I don't intend to get people to get heated up about it. I just don't hold back because people may get heated up about it.
The defense of your original remark implies very strongly that it wasn't
offhand, and that you are indeed trolling. Hence the reduction in the
frequency of my replies. You make it more and more difficult to take you
seriously. Particularly since you have now resorted to a defense which
involves refusing to define a non-existent word in any but the vaguest
terms - you are trying to specify a position on the imaginary continuum
of sanity, but you don't say how close to which end you are trying to
specify. This puts you somewhere between "barmy" and "crackpot" on my
own personal scale.If you are serious about wanting the behaviour changed, and not just whining, then somebody has to come up with an alternative behaviour that is better.
If I would be whining I would want the behaviour changed. I would just keep complaining about it until someone else would have changed it.
Instead you just keep complaining about it, full stop. Since we are all
now fully aware of your opinions, couldn't you just shut up, or do we
have to send you to your room without any supper? Whine, whine, whine.
Sure I would prefer it changed, but it is not that I *want* it to change. I'll happily continue with python if it doesn't change.
That's sort of a pity. At this stage I'd recommend Ruby just to be rid
of the incessant twaddle you come up with to defend your throwaway ideas.
Maybe when someone mentions something negative about python, you shouldn't translate that into someone demanding a change in python.
If not you, then who? Most of the folks who have commented on this thread seem to like the existing behaviour.
Well fine, in that case it won't even change if I do come up with an alternative proposal. So why should I bother?
Absolutely no reason at all. It's already transparently obvious that you
don't have a better alternative and you continue to troll simply because
it validates your particular (and increasingly peculiar) needs.
Every time I reply to you my spell checker looks at your name and shows
me a dialog with an "ignore all" button on it. I have this increasing
suspicion that it's trying to tell me something.
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/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: A |
last post by:
Hi,
I have always been taught to use an inialization list for initialising data
members of a class. I realize that initialsizing primitives and pointers use
an inialization list is exactly the same as an assignment, but for class
types it has a different effect - it calls the copy constructor.
My question is when to not use an initalisation list for initialising data
members of a class?
|
by: xuatla |
last post by:
Hi,
I encountered the following compile error of c++ and hope to get your help.
test2.cpp: In member function `CTest CTest::operator+=(CTest&)':
test2.cpp:79: error: no match for 'operator=' in '*this =
CTest::operator+(CTest&)((+t2))'
test2.cpp:49: error: candidates are: CTest CTest::operator=(CTest&)
make: *** Error 1
|
by: Chris |
last post by:
Hi,
I don't get the difference between a struct and a class !
ok, I know that a struct is a value type, the other a reference type, I
understand the technical differences between both, but conceptually speaking
: when do I define something as 'struct' and when as 'class' ?
for example : if I want to represent a 'Time' thing, containing :
- data members : hours, mins, secs
|
by: NevilleDNZ |
last post by:
Can anyone explain why "begin B: 123" prints, but 456 doesn't?
$ /usr/bin/python2.3 x1x2.py
begin A:
Pre B: 123 456
begin B: 123
Traceback (most recent call last):
File "x1x2.py", line 13, in ?
A()
File "x1x2.py", line 11, in A
|
by: lovecreatesbea... |
last post by:
Could you tell me how many class members the C++ language synthesizes
for a class type? Which members in a class aren't derived from parent
classes?
I have read the book The C++ Programming Language, but there isn't a
detail and complete description on all the class members, aren't they
important to class composing? Could you explain the special class
behavior in detail? Thank you very much.
| |
by: tshad |
last post by:
Using VS 2003, I am trying to take a class that I created to create new
variable types to handle nulls and track changes to standard variable types.
This is for use with database variables. This tells me if a variable has
changed, give me the original and current value, and whether the current
value and original value is/was null or not.
This one works fine but is recreating the same methods over and over for
each variable type.
...
|
by: d.s. |
last post by:
I've got an app with two classes, and one class (InventoryInfoClass)
is an object within the other class (InventoryItem). I'm running into
problems with trying to access (get/set) a private variable within the
included class (InventoryInfo) from the "including" class
(InventoryItem).
Here's the code, trimmed down. I've included ********* at the start
of the first line that's blowing up on me. I'm sure others that try
to access the...
|
by: John Doe |
last post by:
Hi,
I wrote a small class to enumerate available networks on a smartphone :
class CNetwork
{
public:
CNetwork() {};
CNetwork(CString& netName, GUID netguid):
_netname(netName), _netguid(netguid) {}
|
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, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| |
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
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, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |