Idris Brhane

Idris Brhane

1606472580

A Type-safe Postgres Query Builder Pur Sang for Typescript

Mammoth: A type-safe Postgres query builder pur sang for TypeScript

📖 Work-in-progress documentation site is available at https://mammoth.tools/.

npm i @ff00ff/mammoth

Mammoth is a type-safe query builder. It only supports Postgres which we consider a feature. It’s syntax is as close to SQL as possible so you already know how to use it. It’s autocomplete features are great. It helps you avoid mistakes so you can develop applications faster.

const rows = await db
  .select(db.foo.id, db.bar.name)
  .from(db.foo)
  .leftJoin(db.bar)
  .on(db.foo.barId.eq(db.bar.id))
  .where(db.foo.id.eq(`1`));

The above query produces the following SQL:

SELECT
  foo.id,
  bar.name
FROM foo
LEFT JOIN bar ON (foo.bar_id = bar.id)
WHERE
  foo.id = $1

More importantly, the resulting type of rows is { id: string; name: string | undefined }[]. Notice how the name is automatically nullable because of the left join.

Query examples

Basic update

const updateCount = await db.update(db.foo).set({ name: `Test` }).where(db.foo.value.gt(0));
UPDATE foo
SET
  name = $1
WHERE
  value > $2

Basic insert

const rows = await db
  .insertInto(db.foo)
  .values({
    name: `Test`,
    value: 123,
  })
  .returning(`id`);
INSERT INTO foo (
  name,
  value
) VALUES (
  $1,
  $2
)
RETURNING
  id

Insert into select

const affectedCount = await db
  .insertInto(db.foo, ['name'])
  .select(db.bar.name)
  .from(db.bar)
  .where(db.bar.name.isNotNull());
INSERT INTO foo (name)
SELECT
  bar.name
FROM bar
WHERE
  bar.name IS NOT NULL

Select with count(*)

db.select(count()).from(db.foo);
SELECT COUNT(*) FROM foo

Select with aggregate expression

db.select(arrayAgg(db.foo.name.orderBy(db.foo.name.desc()))).from(db.foo);
SELECT array_agg(foo.name ORDER BY foo.name DESC) "arrayAgg" FROM foo

With (CTE) query

db.with(
  `regionalSales`,
  () =>
    db
      .select(db.orderLog.region, sum(db.orderLog.amount).as(`totalSales`))
      .from(db.orderLog)
      .groupBy(db.orderLog.region),
  `topRegions`,
  ({ regionalSales }) =>
    db
      .select(regionalSales.region)
      .from(regionalSales)
      .where(
        regionalSales.totalSales.gt(
          db.select(sum(regionalSales.totalSales).divide(10)).from(regionalSales),
        ),
      ),
  ({ topRegions }) =>
    db
      .select(
        db.orderLog.region,
        db.orderLog.product,
        sum(db.orderLog.quantity).as(`productUnits`),
        sum(db.orderLog.amount).as(`productSales`),
      )
      .from(db.orderLog)
      .where(db.orderLog.region.in(db.select(topRegions.region).from(topRegions)))
      .groupBy(db.orderLog.region, db.orderLog.product),
);
WITH "regionalSales" AS (SELECT order_log.region, SUM (order_log.amount) "totalSales" FROM order_log GROUP BY order_log.region), "topRegions" AS (SELECT "regionalSales".region FROM "regionalSales" WHERE "regionalSales"."totalSales" > (SELECT SUM ("regionalSales"."totalSales") / $1 FROM "regionalSales")) SELECT order_log.region, order_log.product, SUM (order_log.quantity) "productUnits", SUM (order_log.amount) "productSales" FROM order_log WHERE order_log.region IN (SELECT "topRegions".region FROM "topRegions") GROUP BY order_log.region, order_log.product

Quick start

Mammoth is a query builder pur sang so it doesn’t include a database driver. You need to create a db and pass a callback to execute the query.

import { defineDb } from '@ff00ff/mammoth';
import { foo, bar } from './tables';

const db = defineDb({ foo, bar }, async (query, parameters) => {
  const result = await pool.query(query, parameters);

  return {
    affectedCount: result.rowCount,
    rows: result.rows,
  };
});

In the defineDb call you pass all your tables so they can be access through the db instance. You have to define all the tables to make sure Mammoth understands the type information. This should be close to the CREATE TABLE syntax.

const foo = defineTable({
  id: uuid().primaryKey().default(`gen_random_uuid()`),
  createDate: timestampWithTimeZone().notNull().default(`now()`),
  name: text().notNull(),
  value: integer(),
});

You should keep your column names camelCase in the defineTable call as they are automatically transformed to train_case throughout Mammoth.

Compatibility

Below is a list of clauses per query and a short description on what we Mammoth supports.

SELECT

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • SELECT [ ALL | DISTINCT [ ON ( expression [, …] ) ] ] — Mostly supported. Distinct not yet.
  • [ * | expression [ [ AS ] output_name ] [, …] ] — mostly supported. Selecting certain expressions like update queries, insert and delete queries are not supported yet. Select queries are though.
  • [ FROM from_item [, …] ] — partially supported. Only 1 table is currently supported in the from.
  • [ WHERE condition ] — mostly supported. The condition concept is pretty broad but it should contain a lot of cases.
  • [ GROUP BY grouping_element [, …] ] — supported.
  • [ HAVING condition [, …] ] — supported.
  • [ WINDOW window_name AS ( window_definition ) [, …] ] — not supported.
  • [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ] — not supported yet
  • [ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, …] ] — supported, but expressions are pretty broad and there might be cases not covered yet.
  • [ LIMIT { count | ALL } ] — supported.
  • [ OFFSET start [ ROW | ROWS ] ] — supported.
  • [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ] — supported
  • [ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF table_name [, …] ] [ NOWAIT | SKIP LOCKED ] […] ] — supported

UPDATE

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • UPDATE [ ONLY ] table_name [ * ] [ [ AS ] alias ] — supported
  • SET { column_name = { expression | DEFAULT } | — supported, but expression concept is very broad and might be incomplete
  • ( column_name [, …] ) = [ ROW ] ( { expression | DEFAULT } [, …] ) | — supported, but expression concept is very broad and might be incomplete in some cases
  • ( column_name [, …] ) = ( sub-SELECT ) — not supported
  • } [, …]
  • [ FROM from_item [, …] ] — partially supported. Only 1 table as from item is supported
  • [ WHERE condition | WHERE CURRENT OF cursor_name ] — supported, but the condition concept is very broad and is incomplete in some cases.
  • [ RETURNING * | output_expression [ [ AS ] output_name ] [, …] ] — supported, but up to 10 expressions

DELETE

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • DELETE FROM [ ONLY ] table_name [ * ] [ [ AS ] alias ] — supported
  • [ USING from_item [, …] ] — supported
  • [ WHERE condition | WHERE CURRENT OF cursor_name ] — supported, but the condition concept is very broad and might be incomplete
  • [ RETURNING * | output_expression [ [ AS ] output_name ] [, … ] ] — supported, but up to 10 expressions

INSERT

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • INSERT INTO table_name [ AS alias ] [ ( column_name [, …] ) ] — supported
  • [ OVERRIDING { SYSTEM | USER } VALUE ] — not supported
  • { DEFAULT VALUES | VALUES ( { expression | DEFAULT } [, …] ) [, …] | query } - supported, but expression is a broad concept and may not be complete
  • [ ON CONFLICT [ conflict_target ] conflict_action ] — supported
  • [ RETURNING * | output_expression [ [ AS ] output_name ] [, …] ] — supported, but limited to 10 expressions

Versioning

Now that we’ve hit 1.0 Mammoth will stick to semantic versioning, meaning, breaking changes will only be included in major updates.

Contribute

Once you clone the repo, do a npm install + npm run build. Now you should be able to run npm test seeing everything turn green. Feel free to pick up one of the open issues — in particular you can pick up one labeled with “good first issue”. Be sure to claim the issue before you start so we avoid two or more people working on the same thing.

Mammoth logo created by Eucalyp from the Noun Project.

Download Details:

Author: Ff00ff

Demo: https://mammoth.tools/

Source Code: https://github.com/Ff00ff/mammoth

#typescript #deno #nodejs #javascript

What is GEEK

Buddha Community

A Type-safe Postgres Query Builder Pur Sang for Typescript
Idris Brhane

Idris Brhane

1606472580

A Type-safe Postgres Query Builder Pur Sang for Typescript

Mammoth: A type-safe Postgres query builder pur sang for TypeScript

📖 Work-in-progress documentation site is available at https://mammoth.tools/.

npm i @ff00ff/mammoth

Mammoth is a type-safe query builder. It only supports Postgres which we consider a feature. It’s syntax is as close to SQL as possible so you already know how to use it. It’s autocomplete features are great. It helps you avoid mistakes so you can develop applications faster.

const rows = await db
  .select(db.foo.id, db.bar.name)
  .from(db.foo)
  .leftJoin(db.bar)
  .on(db.foo.barId.eq(db.bar.id))
  .where(db.foo.id.eq(`1`));

The above query produces the following SQL:

SELECT
  foo.id,
  bar.name
FROM foo
LEFT JOIN bar ON (foo.bar_id = bar.id)
WHERE
  foo.id = $1

More importantly, the resulting type of rows is { id: string; name: string | undefined }[]. Notice how the name is automatically nullable because of the left join.

Query examples

Basic update

const updateCount = await db.update(db.foo).set({ name: `Test` }).where(db.foo.value.gt(0));
UPDATE foo
SET
  name = $1
WHERE
  value > $2

Basic insert

const rows = await db
  .insertInto(db.foo)
  .values({
    name: `Test`,
    value: 123,
  })
  .returning(`id`);
INSERT INTO foo (
  name,
  value
) VALUES (
  $1,
  $2
)
RETURNING
  id

Insert into select

const affectedCount = await db
  .insertInto(db.foo, ['name'])
  .select(db.bar.name)
  .from(db.bar)
  .where(db.bar.name.isNotNull());
INSERT INTO foo (name)
SELECT
  bar.name
FROM bar
WHERE
  bar.name IS NOT NULL

Select with count(*)

db.select(count()).from(db.foo);
SELECT COUNT(*) FROM foo

Select with aggregate expression

db.select(arrayAgg(db.foo.name.orderBy(db.foo.name.desc()))).from(db.foo);
SELECT array_agg(foo.name ORDER BY foo.name DESC) "arrayAgg" FROM foo

With (CTE) query

db.with(
  `regionalSales`,
  () =>
    db
      .select(db.orderLog.region, sum(db.orderLog.amount).as(`totalSales`))
      .from(db.orderLog)
      .groupBy(db.orderLog.region),
  `topRegions`,
  ({ regionalSales }) =>
    db
      .select(regionalSales.region)
      .from(regionalSales)
      .where(
        regionalSales.totalSales.gt(
          db.select(sum(regionalSales.totalSales).divide(10)).from(regionalSales),
        ),
      ),
  ({ topRegions }) =>
    db
      .select(
        db.orderLog.region,
        db.orderLog.product,
        sum(db.orderLog.quantity).as(`productUnits`),
        sum(db.orderLog.amount).as(`productSales`),
      )
      .from(db.orderLog)
      .where(db.orderLog.region.in(db.select(topRegions.region).from(topRegions)))
      .groupBy(db.orderLog.region, db.orderLog.product),
);
WITH "regionalSales" AS (SELECT order_log.region, SUM (order_log.amount) "totalSales" FROM order_log GROUP BY order_log.region), "topRegions" AS (SELECT "regionalSales".region FROM "regionalSales" WHERE "regionalSales"."totalSales" > (SELECT SUM ("regionalSales"."totalSales") / $1 FROM "regionalSales")) SELECT order_log.region, order_log.product, SUM (order_log.quantity) "productUnits", SUM (order_log.amount) "productSales" FROM order_log WHERE order_log.region IN (SELECT "topRegions".region FROM "topRegions") GROUP BY order_log.region, order_log.product

Quick start

Mammoth is a query builder pur sang so it doesn’t include a database driver. You need to create a db and pass a callback to execute the query.

import { defineDb } from '@ff00ff/mammoth';
import { foo, bar } from './tables';

const db = defineDb({ foo, bar }, async (query, parameters) => {
  const result = await pool.query(query, parameters);

  return {
    affectedCount: result.rowCount,
    rows: result.rows,
  };
});

In the defineDb call you pass all your tables so they can be access through the db instance. You have to define all the tables to make sure Mammoth understands the type information. This should be close to the CREATE TABLE syntax.

const foo = defineTable({
  id: uuid().primaryKey().default(`gen_random_uuid()`),
  createDate: timestampWithTimeZone().notNull().default(`now()`),
  name: text().notNull(),
  value: integer(),
});

You should keep your column names camelCase in the defineTable call as they are automatically transformed to train_case throughout Mammoth.

Compatibility

Below is a list of clauses per query and a short description on what we Mammoth supports.

SELECT

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • SELECT [ ALL | DISTINCT [ ON ( expression [, …] ) ] ] — Mostly supported. Distinct not yet.
  • [ * | expression [ [ AS ] output_name ] [, …] ] — mostly supported. Selecting certain expressions like update queries, insert and delete queries are not supported yet. Select queries are though.
  • [ FROM from_item [, …] ] — partially supported. Only 1 table is currently supported in the from.
  • [ WHERE condition ] — mostly supported. The condition concept is pretty broad but it should contain a lot of cases.
  • [ GROUP BY grouping_element [, …] ] — supported.
  • [ HAVING condition [, …] ] — supported.
  • [ WINDOW window_name AS ( window_definition ) [, …] ] — not supported.
  • [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ] — not supported yet
  • [ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, …] ] — supported, but expressions are pretty broad and there might be cases not covered yet.
  • [ LIMIT { count | ALL } ] — supported.
  • [ OFFSET start [ ROW | ROWS ] ] — supported.
  • [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ] — supported
  • [ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF table_name [, …] ] [ NOWAIT | SKIP LOCKED ] […] ] — supported

UPDATE

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • UPDATE [ ONLY ] table_name [ * ] [ [ AS ] alias ] — supported
  • SET { column_name = { expression | DEFAULT } | — supported, but expression concept is very broad and might be incomplete
  • ( column_name [, …] ) = [ ROW ] ( { expression | DEFAULT } [, …] ) | — supported, but expression concept is very broad and might be incomplete in some cases
  • ( column_name [, …] ) = ( sub-SELECT ) — not supported
  • } [, …]
  • [ FROM from_item [, …] ] — partially supported. Only 1 table as from item is supported
  • [ WHERE condition | WHERE CURRENT OF cursor_name ] — supported, but the condition concept is very broad and is incomplete in some cases.
  • [ RETURNING * | output_expression [ [ AS ] output_name ] [, …] ] — supported, but up to 10 expressions

DELETE

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • DELETE FROM [ ONLY ] table_name [ * ] [ [ AS ] alias ] — supported
  • [ USING from_item [, …] ] — supported
  • [ WHERE condition | WHERE CURRENT OF cursor_name ] — supported, but the condition concept is very broad and might be incomplete
  • [ RETURNING * | output_expression [ [ AS ] output_name ] [, … ] ] — supported, but up to 10 expressions

INSERT

  • [ WITH [ RECURSIVE ] with_query [, …] ] — Partial support. Recursive not supported yet.
  • INSERT INTO table_name [ AS alias ] [ ( column_name [, …] ) ] — supported
  • [ OVERRIDING { SYSTEM | USER } VALUE ] — not supported
  • { DEFAULT VALUES | VALUES ( { expression | DEFAULT } [, …] ) [, …] | query } - supported, but expression is a broad concept and may not be complete
  • [ ON CONFLICT [ conflict_target ] conflict_action ] — supported
  • [ RETURNING * | output_expression [ [ AS ] output_name ] [, …] ] — supported, but limited to 10 expressions

Versioning

Now that we’ve hit 1.0 Mammoth will stick to semantic versioning, meaning, breaking changes will only be included in major updates.

Contribute

Once you clone the repo, do a npm install + npm run build. Now you should be able to run npm test seeing everything turn green. Feel free to pick up one of the open issues — in particular you can pick up one labeled with “good first issue”. Be sure to claim the issue before you start so we avoid two or more people working on the same thing.

Mammoth logo created by Eucalyp from the Noun Project.

Download Details:

Author: Ff00ff

Demo: https://mammoth.tools/

Source Code: https://github.com/Ff00ff/mammoth

#typescript #deno #nodejs #javascript

Ahebwe  Oscar

Ahebwe Oscar

1620185280

How model queries work in Django

How model queries work in Django

Welcome to my blog, hey everyone in this article we are going to be working with queries in Django so for any web app that you build your going to want to write a query so you can retrieve information from your database so in this article I’ll be showing you all the different ways that you can write queries and it should cover about 90% of the cases that you’ll have when you’re writing your code the other 10% depend on your specific use case you may have to get more complicated but for the most part what I cover in this article should be able to help you so let’s start with the model that I have I’ve already created it.

**Read More : **How to make Chatbot in Python.

Read More : Django Admin Full Customization step by step

let’s just get into this diagram that I made so in here:

django queries aboutDescribe each parameter in Django querset

we’re making a simple query for the myModel table so we want to pull out all the information in the database so we have this variable which is gonna hold a return value and we have our myModel models so this is simply the myModel model name so whatever you named your model just make sure you specify that and we’re gonna access the objects attribute once we get that object’s attribute we can simply use the all method and this will return all the information in the database so we’re gonna start with all and then we will go into getting single items filtering that data and go to our command prompt.

Here and we’ll actually start making our queries from here to do this let’s just go ahead and run** Python manage.py shell** and I am in my project file so make sure you’re in there when you start and what this does is it gives us an interactive shell to actually start working with our data so this is a lot like the Python shell but because we did manage.py it allows us to do things a Django way and actually query our database now open up the command prompt and let’s go ahead and start making our first queries.

#django #django model queries #django orm #django queries #django query #model django query #model query #query with django

Christa  Stehr

Christa Stehr

1599315360

Nominal typing in Typescript

Nominal & structural typing

Type systems are typically categorized as either structural or nominal. Languages like Java and Scala have primarily nominal type systems, whereas a language like Typescript has a structural type system. Let’s take a brief look at both systems.

Nominal Typing

In a nominal typing system, type compatibility is checked using the name of the types. If they do not have the same name, then they are not compatible; end of story. **If **Typescript had a nominal typing system the type check for the last line would fail:

Image for post

Structural typing

Typescript uses structural typing to decide whether two types are compatible with one another or not. What do we mean by structural typing? Well, let’s consider the following code snippet:

Image for post

To determine whether the type of the constant color(RGBA) is compatible with the type of serializeColor’s parameter x(RGB) the type system must verify that each member of RGB has a corresponding compatible member in RGBA. In this case, RGB has a single member color for which RGBA has a corresponding member with the same type — [number, number, number] — and so it passes the type check. Notice how the type system ignores the additional members that exist on RGBA (alpha).

#typescript #type-safe #type-systems

Mammoth 1.0: A New TypeScript Postgres Query Builder

It’s been almost 3 years since I started working on this query builder idea of mine. Today is finally the day Mammoth hits 1.0. Mammoth is a no-batteries-included type-safe Postgres query builder for TypeScript. Hooray!

db.with(
  `regionalSales`,
  () =>
    db
      .select(db.orderLog.region, sum(db.orderLog.amount).as(`totalSales`))
      .from(db.orderLog)
      .groupBy(db.orderLog.region),
  `topRegions`,
  ({ regionalSales }) =>
    db
      .select(regionalSales.region)
      .from(regionalSales)
      .where(
        regionalSales.totalSales.gt(
          db.select(sum(regionalSales.totalSales).divide(10)).from(regionalSales),
        ),
      ),
  ({ topRegions }) =>
    db
      .select(
        db.orderLog.region,
        db.orderLog.product,
        sum(db.orderLog.quantity).as(`productUnits`),
        sum(db.orderLog.amount).as(`productSales`),
      )
      .from(db.orderLog)
      .where(db.orderLog.region.in(db.select(topRegions.region).from(topRegions)))
      .groupBy(db.orderLog.region, db.orderLog.product),
);

The no-batteries-included part is a wink to Knex.js and hints at Mammoth’s opposing ideas. Knex.js supports many SQL dialects and bundles the approriate database drivers (as peer dependencies, yes). Mammoth, however, only supports one SQL dialect, Postgres, and bundles no database driver.

Creating a cross-database query builder like Knex.js is an amazing challenge, one that Knex.js set out to take on, but not me. To me, creating a cross-database query builder basically means constructing a new SQL dialect. For all the differences in the existing dialects you have to construct a new generic concept. But I like SQL. It’s ubiquoutus and versatile. Especially Postgres. And this new language wouldn’t be.

In Knex.js the INSERT INTO … ON CONFLICT is nowhere to be found. This SQL clause is missing even though it’s been released more than 4 years ago. The problem? The contributors had to introduce a new concept and try to avoid anything database-specific. I think this is an example how hard it is to create this new cross-database language. Weighing the pros and cons without being database-specific. This challenge becomes clear in this pull request discussing insert into on conflict.

An often touted benefit of a cross-database solution is to be able to easily switch between different databases. Not at runtime but if you later decide to migrate from one database to another. But a cross-database approach isn’t the only option. Instead, I think, a multi-database solution is a good strategy when you’re operating in a type-safe world. Where the former focusses on speaking to different databases using a single API, the latter offers a database-specific API, but type-safe, thus, multi. Meaning, you would still be able to switch between databases, and you would see breaking changes at compile time. Fix the errors and you can be confident you support the new database.

Of course this ignores the whole topic of needing to actually migrate data from one database to another. This is why, in my opinion, you never really just switch from one database to another.

Mammoth is sticking as close to SQL as possible. This comes with a set of challenges when building Mammoth, but it should make it easier to adopt Mammoth in a project or onboard new developers. I want a minimal abstraction, not a new generic SQL language, an ORM or something even more massive like Prisma. If you want to speak to your database, but it requires re-learning a lot you already know how to do in SQL, something is wrong. And all this re-learning is often not transferable to different languages or environment, which makes part of this learning wasteful.

As an alternative, there are amazing tools available which generate types by reading your queries and reading the remote database schema. While these do solve the type-safety challenges and stick to SQL, I feel requiring a watch on file changes so types can get re-generated isn’t ideal. Instead, with an advanced enough type-safe query builder you can have the same features without this build step.

Mammoth aims to fix exactly that. Here are some examples that I think work great. All the result types are automatically inferred.

#typescript #postgres #database #programming #developer

Arvel  Parker

Arvel Parker

1593156510

Basic Data Types in Python | Python Web Development For Beginners

At the end of 2019, Python is one of the fastest-growing programming languages. More than 10% of developers have opted for Python development.

In the programming world, Data types play an important role. Each Variable is stored in different data types and responsible for various functions. Python had two different objects, and They are mutable and immutable objects.

Table of Contents  hide

I Mutable objects

II Immutable objects

III Built-in data types in Python

Mutable objects

The Size and declared value and its sequence of the object can able to be modified called mutable objects.

Mutable Data Types are list, dict, set, byte array

Immutable objects

The Size and declared value and its sequence of the object can able to be modified.

Immutable data types are int, float, complex, String, tuples, bytes, and frozen sets.

id() and type() is used to know the Identity and data type of the object

a**=25+**85j

type**(a)**

output**:<class’complex’>**

b**={1:10,2:“Pinky”****}**

id**(b)**

output**:**238989244168

Built-in data types in Python

a**=str(“Hello python world”)****#str**

b**=int(18)****#int**

c**=float(20482.5)****#float**

d**=complex(5+85j)****#complex**

e**=list((“python”,“fast”,“growing”,“in”,2018))****#list**

f**=tuple((“python”,“easy”,“learning”))****#tuple**

g**=range(10)****#range**

h**=dict(name=“Vidu”,age=36)****#dict**

i**=set((“python”,“fast”,“growing”,“in”,2018))****#set**

j**=frozenset((“python”,“fast”,“growing”,“in”,2018))****#frozenset**

k**=bool(18)****#bool**

l**=bytes(8)****#bytes**

m**=bytearray(8)****#bytearray**

n**=memoryview(bytes(18))****#memoryview**

Numbers (int,Float,Complex)

Numbers are stored in numeric Types. when a number is assigned to a variable, Python creates Number objects.

#signed interger

age**=**18

print**(age)**

Output**:**18

Python supports 3 types of numeric data.

int (signed integers like 20, 2, 225, etc.)

float (float is used to store floating-point numbers like 9.8, 3.1444, 89.52, etc.)

complex (complex numbers like 8.94j, 4.0 + 7.3j, etc.)

A complex number contains an ordered pair, i.e., a + ib where a and b denote the real and imaginary parts respectively).

String

The string can be represented as the sequence of characters in the quotation marks. In python, to define strings we can use single, double, or triple quotes.

# String Handling

‘Hello Python’

#single (') Quoted String

“Hello Python”

# Double (") Quoted String

“”“Hello Python”“”

‘’‘Hello Python’‘’

# triple (‘’') (“”") Quoted String

In python, string handling is a straightforward task, and python provides various built-in functions and operators for representing strings.

The operator “+” is used to concatenate strings and “*” is used to repeat the string.

“Hello”+“python”

output**:****‘Hello python’**

"python "*****2

'Output : Python python ’

#python web development #data types in python #list of all python data types #python data types #python datatypes #python types #python variable type