473,739 Members | 2,385 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP

In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces " module
instead. Some of my reasons:

(1) Namespace is feeling less and less like a collection to me. Even
though it's still intended as a data-only structure, the use cases seem
pretty distinct from other collections.

(2) I think there are a couple different types that should be provided,
not just one. For example:

* The suggested namespace view (which allows, for example, globals() to
be manipulated with the getattr protocol) should probably be its own
class, NamespaceView, since the behavior of a NamespaceView is
substantially different from that of a Namespace. (Modifying a
NamespaceView modifies the dict, while modifying a Namespace doesn't.)
This also allows NamespaceView to have a separate __repr__ to indicate
some of the differences.

* The suggested namespace chain, if included, should also probably be
its own class, NamespaceChain. As defined, it doesn't depend on
Namespace at all -- it could be used just as well for other
non-Namespace objects...
I've updated the PEP to reflect these changes. Comments and suggestions
greatly appreciated! (Note that I've included the current
implementation of the module at the end of the PEP.)

----------------------------------------------------------------------
PEP: XXX
Title: Attribute-Value Mapping Data Type
Version:
Last-Modified:
Author: Steven Bethard <st************ @gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-Feb-2005
Python-Version: 2.5
Post-History: 10-Feb-2005
Abstract
========

This PEP proposes a standard library addition to support the simple
creation of attribute-value mappping objects which can be given named
attributes without the need to declare a class. Such attribute-value
mappings are intended to complement the name-value mappings provided
by Python's builtin dict objects.
Motivation
==========

Python's dict objects provide a simple way of creating anonymous
name-value mappings. These mappings use the __getitem__ protocol to
access the value associated with a name, so that code generally
appears like::

mapping['name']

Occasionally, a programmer may decide that dotted-attribute style
access is more appropriate to the domain than __getitem__ style
access, and that their mapping should be accessed like::

mapping.name

Currently, if a Python programmer makes this design decision, they
are forced to declare a new class, and then build instances of this
class. When no methods are to be associated with the attribute-value
mappings, declaring a new class can be overkill. This PEP proposes
adding a new module to the standard library to provide a few simple
types that can be used to build such attribute-value mappings.

Providing such types allows the Python programmer to determine which
type of mapping is most appropriate to their domain and apply this
choice with minimal effort. Some of the suggested uses include:
Returning Named Results
-----------------------

It is often appropriate for a function that returns multiple items to
give names to the different items returned. The types suggested in
this PEP provide a simple means of doing this that allows the
returned values to be accessed in the usual attribute-style access::
def f(x): ... return Namespace(doubl e=2*x, squared=x**2)
... y = f(10)
y.double 20 y.squared 100
Representing Hierarchical Data
------------------------------

The types suggested in this PEP also allow a simple means of
representing hierarchical data that allows attribute-style access::
x = Namespace(spam= Namespace(rabbi t=1, badger=[2]), ham='3')
x.spam.badger [2] x.ham '3'
Manipulating Dicts through Attributes
-------------------------------------

Sometimes it is desirable to access the items of an existing dict
object using dotted-attribute style access instead of __getitem__
style access. The types suggested in this PEP provide a simple means
of doing so::
d = {'name':'Pervis ', 'lumberjack':Tr ue}
ns = NamespaceView(d )
ns NamespaceView(l umberjack=True, name='Pervis') ns.rugged = False
del ns.lumberjack
d {'rugged': False, 'name': 'Pervis'}
Rationale
=========

As Namespace objects are intended primarily to replace simple,
data-only classes, simple Namespace construction was a primary
concern. As such, the Namespace constructor supports creation from
keyword arguments, dicts, and sequences of (attribute, value) pairs::
Namespace(eggs= 1, spam=2, ham=3)

Namespace(eggs= 1, ham=3, spam=2) Namespace({'egg s':1, 'spam':2, 'ham':3}) Namespace(eggs= 1, ham=3, spam=2) Namespace([('eggs',1), ('spam',2), ('ham',3)]) Namespace(eggs= 1, ham=3, spam=2)

To allow attribute-value mappings to be easily combined, the
Namespace type provides a update staticmethod that supports similar
arguments::
ns = Namespace(eggs= 1)
Namespace.updat e(ns, [('spam', 2)], ham=3)
ns Namespace(eggs= 1, ham=3, spam=2)

Note that update should be used through the class, not through the
instances, to avoid the confusion that might arise if an 'update'
attribute added to a Namespace instance hid the update method.
Namespace objects support also object equality, comparing Namespace
objects by attributes recursively::
x = Namespace(parro t=Namespace(lum berjack=True, spam=42), peng='shrub') y = Namespace(peng= 'shrub', parrot=Namespac e(spam=42, lumberjack=True )) z = Namespace(parro t=Namespace(lum berjack=True), peng='shrub')
x == y True x == z False
NamespaceView objects are intended to allow manipulating dict objects
through the getattr protocol instead of the getitem protocol. For
example usage, see "Viewing Dict Items as Attributes" above.
Note that support for the various mapping methods, e.g.
__(get|set|del) item__, __len__, __iter__, __contains__, items, keys,
values, etc. was intentionally omitted as these methods did not seem
to be necessary for the core uses of an attribute-value mapping. If
such methods are truly necessary for a given use case, this may
suggest that a dict object is a more appropriate type for that use.
Examples
=========

Converting an XML DOM tree into a tree of nested Namespace objects::
import xml.dom.minidom
def gettree(element ): ... result = Namespace()
... if element.attribu tes:
... Namespace.updat e(result, element.attribu tes.items())
... children = {}
... for child in element.childNo des:
... if child.nodeType == xml.dom.minidom .Node.TEXT_NODE :
... children.setdef ault('text', []).append(
... child.nodeValue )
... else:
... children.setdef ault(child.node Name, []).append(
... gettree(child))
... Namespace.updat e(result, children)
... return result
... doc = xml.dom.minidom .parseString("" "\ ... <xml>
... <a attr_a="1">
... a text 1
... <b attr_b="2" />
... <b attr_b="3"> b text </b>
... a text 2
... </a>
... <c attr_c="4"> c text </c>
... </xml>""") tree = gettree(doc.doc umentElement)
tree.a[0].b[1]

Namespace(attr_ b=u'3', text=[u' b text '])

Reference Implementation
=============== =========

::
class Namespace(objec t):
"""Namespac e([namespace|dict| seq], **kwargs) -> Namespace object

The new Namespace object's attributes are initialized from (if
provided) either another Namespace object's attributes, a
dictionary, or a sequence of (name, value) pairs, then from the
name=value pairs in the keyword argument list.
"""

def __init__(*args, **kwargs):
"""Initiali zes a Namespace instance."""
# inheritance-friendly update call
type(args[0]).update(*args, **kwargs)

def __eq__(self, other):
"""x.__eq__ (y) <==> x == y

Two Namespace objects are considered equal if they have the
same attributes and the same values for each of those
attributes.
"""
return (other.__class_ _ == self.__class__ and
self.__dict__ == other.__dict__)

def __repr__(self):
"""x.__repr __() <==> repr(x)

If all attribute values in this namespace (and any nested
namespaces) are reproducable with eval(repr(x)), then the
Namespace object is also reproducable for eval(repr(x)).
"""
return '%s(%s)' % (
type(self).__na me__,
', '.join('%s=%r' % (k, v) for k, v in sorted(
self.__dict__.i teritems())))

def update(*args, **kwargs):
"""Namespace.up date(ns, [ns|dict|seq,] **kwargs) -> None

Updates the first Namespace object's attributes from (if
provided) either another Namespace object's attributes, a
dictionary, or a sequence of (name, value) pairs, then from
the name=value pairs in the keyword argument list.
"""
if not 1 <= len(args) <= 2:
raise TypeError('expe cted 1 or 2 arguments, got %i' %
len(args))
self = args[0]
if not isinstance(self , Namespace):
raise TypeError('firs t argument to update should be '
'Namespace, not %s' %
type(self).__na me__)
if len(args) == 2:
other = args[1]
if isinstance(othe r, Namespace):
other = other.__dict__
try:
self.__dict__.u pdate(other)
except (TypeError, ValueError):
raise TypeError('cann ot update Namespace with %s' %
type(other).__n ame__)
self.__dict__.u pdate(kwargs)
class NamespaceView(N amespace):
"""NamespaceVie w(dict) -> new Namespace view of the dict

Creates a Namespace that is a view of the original dictionary,
that is, changes to the Namespace object will be reflected in
the dictionary, and vice versa.
"""
def __init__(self, d):
self.__dict__ = d
Open Issues
===========
What should the types be named? Some suggestions include 'Bunch',
'Record', 'Struct' and 'Namespace'.

Where should the types be placed? The current suggestion is a new
"namespaces " module.

Should namespace chaining be supported? One suggestion would add a
NamespaceChain object to the module::

class NamespaceChain( object):
"""NamespaceCha in(*objects) -> new attribute lookup chain

The new NamespaceChain object's attributes are defined by the
attributes of the provided objects. When an attribute is
requested, the sequence is searched sequentially for an object
with such an attribute. The first such attribute found is
returned, or an AttributeError is raised if none is found.

Note that this chaining is only provided for getattr and delattr
operations -- setattr operations must be applied explicitly to
the appropriate objects.

The list of objects is stored in a NamespaceChain object's
__namespaces__ attribute.
"""
def __init__(self, *objects):
"""Initiali ze the NamespaceChain object"""
self.__namespac es__ = objects

def __getattr__(sel f, name):
"""Return the first such attribute found in the object list
"""
for obj in self.__namespac es__:
try:
return getattr(obj, name)
except AttributeError:
pass
raise AttributeError( name)

def __delattr__(sel f, name):
"""Delete the first such attribute found in the object list
"""
for obj in self.__namespac es__:
try:
return delattr(obj, name)
except AttributeError:
pass
raise AttributeError( name)
References
==========


...
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
Jul 18 '05 #1
18 3048
On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote:
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces " module instead.


Context: I've never been excited by this proposal.

But I am intrigued to note that with a couple of differences, you've now
converged on a module I've already written for my own use, which I called
a Registry. I actually subclassed 'dict', added some methods to use
dotted-access as you describe, and added some methods for accessing and
initializing a deeper key (basically a "get" that can handle hierarchy)
and a couple of other things.

There are worse things for application config storing than a pickled
Namespace. (Not human readable, but if you don't care about that, as I
generally don't, it's close to usable.)
Jul 18 '05 #2
Jeremy Bowers wrote:
On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote:
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces " module instead.


Context: I've never been excited by this proposal.

But I am intrigued to note that with a couple of differences, you've now
converged on a module I've already written for my own use, which I called
a Registry.


Yeah, I guess that was really the motivation of this module. I
personally wouldn't use it all that often -- certainly not with the
frequency that I use, say, Python 2.4's set type -- but I think there
are enough of us out here who have written essentially the same module
enough times that it merits a little bit of standardization and addition
to the standard library.

Steve
Jul 18 '05 #3
On Thu, 10 Feb 2005 13:39:29 -0700, Steven Bethard wrote:
Yeah, I guess that was really the motivation of this module. I
personally wouldn't use it all that often -- certainly not with the
frequency that I use, say, Python 2.4's set type -- but I think there
are enough of us out here who have written essentially the same module
enough times that it merits a little bit of standardization and addition
to the standard library.


If it expands past what was basically a slight elaboration on

class Bunch: pass

to actually do real work, I'd be much more impressed, as long as simple
things stay simple. A hierarchy-aware get might be a good start:
config = Namespace()
myParm = config.get("mya pp.wrapping.lin e", constants.STRIC T)
someParms = config.get("mya pp.settings.pri nter", Namespace())


which would create the necessary namespaces or something.
Jul 18 '05 #4
I like it alot! My only minor complaint is that the name is to long.
Also I *really wish* the Namespace could do this:

r, g, b = col = Namespace(r = 4, g = 3, b = 12)

But alas, I guess that's not doable within the scope of the Namespace PEP.

--
mvh Björn
Jul 18 '05 #5
BJörn Lindqvist wrote:
I like it alot! My only minor complaint is that the name is to long.
Also I *really wish* the Namespace could do this:

r, g, b = col = Namespace(r = 4, g = 3, b = 12)

But alas, I guess that's not doable within the scope of the Namespace PEP.


You can almost spell that already, it just won't do what you want:

r, g, b = col = dict(r = 4, g = 3, b = 12).values()

The dict-based implementation means named tuples they ain't :)

However, the namespaces module *would* provide a natural location for a
NamedTuple class.

Cheers,
Nick.

--
Nick Coghlan | nc******@email. com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #6
Jeremy Bowers <je**@jerf.or g> wrote in message news:<pa******* *************** ******@jerf.org >...
On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote:
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces " module instead.


Context: I've never been excited by this proposal.

But I am intrigued to note that with a couple of differences, you've now
converged on a module I've already written for my own use, which I called
a Registry. I actually subclassed 'dict', added some methods to use
dotted-access as you describe, and added some methods for accessing and
initializing a deeper key (basically a "get" that can handle hierarchy)
and a couple of other things.

There are worse things for application config storing than a pickled
Namespace. (Not human readable, but if you don't care about that, as I
generally don't, it's close to usable.)


FWIW, you can count me about the people who (re)wrote this same thing
(actually with some difference, since I wanted to keep the order, so
I used nested lists instead of nested dictionaries, but the idea was
similar). I would welcome some module in the standard library to store
hierarchical data.

Michele Simionato
Jul 18 '05 #7
Steven Bethard wrote:
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces " module
instead. Some of my reasons:

(1) Namespace is feeling less and less like a collection to me. Even
though it's still intended as a data-only structure, the use cases seem
pretty distinct from other collections.
Particularly since the collections module is billed as a location for
purpose-specific optimised data structures where some general-purpose features
have been dropped in order to make other aspects faster.

All the ideas here relate to conveniently manipulating namespaces, and are
independent enough to make sense as separate classes. I think a new module is a
good call.

It also allows a Python implementation :)
>>> ns = Namespace(eggs= 1)
>>> Namespace.updat e(ns, [('spam', 2)], ham=3)
>>> ns

Namespace(eggs= 1, ham=3, spam=2)

Note that update should be used through the class, not through the
instances, to avoid the confusion that might arise if an 'update'
attribute added to a Namespace instance hid the update method.


I'd like to see the PEP text itself encourage the more inheritance friendly
style used in the __init__ method:
type(ns).update (ns, [('spam', 2)], ham=3)

Accessing the class directly means that you may get incorrect behaviour if ns is
actually an instance of a subclass of Namespace that overrides update.

It may also be worth mentioning that the standard library applies this technique
in order to reliably access the magic methods of an instance's type, rather than
the versions shadowed in the instance (this is important when trying to pickle
or copy instances of 'type' for example).
Note that support for the various mapping methods, e.g.
__(get|set|del) item__, __len__, __iter__, __contains__, items, keys,
values, etc. was intentionally omitted as these methods did not seem
to be necessary for the core uses of an attribute-value mapping. If
such methods are truly necessary for a given use case, this may
suggest that a dict object is a more appropriate type for that use.
The 'vars' builtin also makes it trivial to use dictionary style operations to
manipulate the contents of a Namespace.
class Namespace(objec t):
def __eq__(self, other):
"""x.__eq__ (y) <==> x == y

Two Namespace objects are considered equal if they have the
same attributes and the same values for each of those
attributes.
"""
return (other.__class_ _ == self.__class__ and
self.__dict__ == other.__dict__)
Hmm, the exact class check strikes me as being rather strict. Although I guess
it makes sense, as the loose check is easily spelt:
if vars(ns1) == vars(ns2): pass

*shrug* I'll let other people argue about this one :)
def update(*args, **kwargs):
"""Namespace.up date(ns, [ns|dict|seq,] **kwargs) -> None
Same comment as above about encouraging the inheritance friendly style.
Open Issues
===========
What should the types be named? Some suggestions include 'Bunch',
'Record', 'Struct' and 'Namespace'.
Where should the types be placed? The current suggestion is a new
"namespaces " module.
If there aren't any objections to the current answers to these questions in this
thread, you may finally get to move them to a 'Resolved Issues' section :)
Should namespace chaining be supported? One suggestion would add a
NamespaceChain object to the module::
This does have the advantage of keeping the basic namespace simple. However, it
may also be worth having native chaining support in Namespace:

class Namespace(objec t):
def __init__(*args, **kwds):
if not 1 <= len(args) <= 3:
raise TypeError('expe cted 1 to 3 non-keyword arguments,'
'got %i' % len(args))
self = args[0]
# Set __fallback__ first, so keyword arg can override
if len(args) > 2:
self.__fallback __ = args[2]
else:
self.__fallback __ = None
# Update __dict__. OK to use normal method calls, since dict hasn't
# been updated yet
if len(args) > 1 and args[1] is not None:
self.update(arg s[1], **kwds)
elif kwds:
self.update(**k wds)

def __getattr__(sel f, attr):
if self.__fallback __ is not None:
return getattr(self.__ fallback__, attr)
raise AttributeError( "No attribute named " + attr)

# Otherwise unchanged
class NamespaceChain( object):
"""NamespaceCha in(*objects) -> new attribute lookup chain

The new NamespaceChain object's attributes are defined by the
attributes of the provided objects. When an attribute is
requested, the sequence is searched sequentially for an object
with such an attribute. The first such attribute found is
returned, or an AttributeError is raised if none is found.

Note that this chaining is only provided for getattr and delattr
operations -- setattr operations must be applied explicitly to
the appropriate objects.


Hmm, I'm not so sure about this. I think that the right model is the way that a
class instance is currently chained with its class.

That is, assume we have the following:
c = cls()
ns = Namespace(vars( c), vars(cls)) # Using modified NS above
nc = NamespaceChain( Namespace(vars( c)), Namespace(vars( cls)))
I would expect modification of attributes on ns or nc to behave similarly to
modification of attributes on c - attribute retrieval follows the chain, but
attribute modification (set/del) always operates on the first namespace in the
chain.

Cheers,
Nick.
--
Nick Coghlan | nc******@email. com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #8
Michele Simionato wrote:
FWIW, you can count me about the people who (re)wrote this same thing
(actually with some difference, since I wanted to keep the order, so
I used nested lists instead of nested dictionaries, but the idea was
similar). I would welcome some module in the standard library to store
hierarchical data.


This is one of the reasons why Steven's idea of switching to proposing a new
module is a good one. It then provides a natural location for any future
extensions of the idea such as Records (i.e. namespaces with a defined set of
legal fields) and NamedTuples and NamedLists (i.e. namespaces with a defined
field order)

Cheers,
Nick

--
Nick Coghlan | nc******@email. com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #9
On Fri, 11 Feb 2005 22:23:58 +1000, Nick Coghlan wrote:
This is one of the reasons why Steven's idea of switching to proposing a
new module is a good one. It then provides a natural location for any
future extensions of the idea such as Records (i.e. namespaces with a
defined set of legal fields) and NamedTuples and NamedLists (i.e.
namespaces with a defined field order)


I'm not very good at reading Guido's mind, but it might be worth feeling
out whether mentioning this will improve the chances of this passing or
not, because while I do not know, can not know, and am not trying to
predict, it is at least possible that Guido may feel as I have been: That
this proposal on its own isn't that exciting, but as the foundation of
some *other* standard functionality as described it might be very good. In
that case that should be emphasized.

See, now it still doesn't make me jump up and down because I can write
what I need fairly easily, but it would be a great boon to beginners or
people who just want to do work and re-write this again, but slightly
differently, and would also provide some standardization where otherwise
we all roll our not-quite-similar-enough implementations , which would help
us read each other's code.

Y'all are bringing me around, slowly but surely :-)
Jul 18 '05 #10

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

Similar topics

24
3521
by: Marcin Vorbrodt | last post by:
Here is an example of my code: //Header file #include <vector> using std::vector; namespace Revelation { // class definitions, etc... // class members are of type std::vector }
3
1361
by: Jeremy Moles | last post by:
Just a quick question before I waste time doing something that will immediately be disregarded as unacceptable code... :) When using the C API and writing extension modules, how do you normally pass a structure up into the python module? For instance, if I have a structure: typedef struct Foo { int x; int y;
17
2073
by: clintonG | last post by:
Using 2.0 with Master Pages and a GlobalBaseClass for the content pages. I understand the easy part -- the hierarchical structure of a namespace naming convention -- but the 2.0 IDE does not write a signature for the developer and after getting a good start developing a 2.0 application I thought I should go through the code and start marking classes and with namespaces. I keep getting the following 'missing' error even when using a first...
12
3599
by: Sadeq | last post by:
Is there a way to read a struct field by field? I want to write a rather general function, like: public string EncodeStruct (struct strct) { .... } which accepts a general struct type, reads it field by field, encodes
5
1495
by: bugbear | last post by:
I need to do some fairly simple processing of XML files; I would like to be able to do this in perl. However, the XML I'm handling uses namespaces. In practice, the tags do not overlap, so I could achieve the functionality I need by simply stripping namespace information.
15
1803
by: kwikius | last post by:
Hi all, I have been searching through the list of papers at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ I seem to remember a proposal regarding templated namespaces e.g: template <typename T> namespace X{
11
4713
by: redefined.horizons | last post by:
First, I would thank all of those that took the time to answer my question about creating an array based on a numeric value stored in a variable. I realize after reading the responses and doing some more research, that what I really need is known in C as a "dynamic array". Basically, you surpass the array notation and use pointers with memory obtained with malloc() or calloc(). I think this will do just what I needed. That has brought...
6
8512
by: Raj Wall | last post by:
Hi, I am trying to implement the IEqualityComparer interface for a struct so I can use it as the Key for a Dictionary. My struct declaration has: public struct Ring : IEqualityComparer { .... } and I am trying to implement the Equals and GetHashCode methods.
5
6387
by: hnshashi | last post by:
I have writtem kernel(2.4) module to commu. with user space appl. using netlink socket. I am getting compilation error. kernel module:-> #include <linux/skbuff.h> #include<linux/module.h> #include <linux/socket.h> #include <linux/config.h> #include <linux/module.h> #include <linux/kernel.h>
0
8794
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,...
0
9341
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 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...
0
9211
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
8216
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, 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...
1
6756
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4572
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...
0
4826
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3282
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2748
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.