Devsearch Synopsis

“Devsearch”
MAJOR PROJECT REPORT (KCA-451)
SUBMITTED TO
DR. A.P.J. ABDUL KALAM TECHNICAL UNIVERSITY, LUCKNOW

(U.P.)
FOR THE PARTIAL FULFILLMENT OF THE DEGREE OF MASTER
IN COMPUTER APPLICATION SESSION (2022-24)
Under the Guidance of Submitted by:
Prof. Mr. Shailender Vats Naina Sharma (2200980140026)

Assistant Professor Rohit Rajput (2200980140035)
School of Sudhanshu Vishwakarma (2200980140044)
IT IMS-Noida
INSTITUTE OF MANAGEMENT STUDIES, NOIDA

1. Roll No.: 2200980140026, 2200980140035, 2200980140044
2. Name of the student: Naina Sharma, Rohit Rajput, Sudhanshu Vishwakarma
3. E-mail:
rohitrajput.mca22028@gmail.com,
nainasharma.mca22013@gmail.com,
sudhanshuvishwakarma.mca22029@imsnoida.com
4. Mob. No.- 9354382169, 8860473773, 8853451387
5. Title of the Major Project: Devsearch
6. Name of the Guide: Mr. Shailender Vats
For Office Use Only:
Signature of the Mentor
Approved Not Approved Date:
Suggestions (if any):-
2
INDEX
S.No. Description Page No.

1. Project Profile
1.1 Project Definition
1.2 Project Description
1.3 Existing System / Work Environment
1.4 Problem Statements
1.5 Need for New System
1.6 Proposed System & Features
1.7 Scope
1.8 Outcomes
1.9 Tools & Technology Used
1.10 Project Plan
2. Requirement Analysis
2.1 Feasibility Study
2.2 Users of the System
2.3 Modules
2.4 Hardware & Software Requirements
3. Design
3.1 Diagrams
3.1.1 DFD
3.1.2 Entity Relationship Diagram
4. Implementation
4.1 Code
5. Testing
5.1 Test Strategy/Test Cases
6. Future Enhancement
7. Screenshot
8. Bibliography
3
ACKNOWLEDGEMENT
I am very grateful to my Major project (KCA-451) Mr. Shailender Vats, for

giving his valuable time and constructive guidance in preparing the
Report-Major Project (KCA-451). It would not have been possible to work
on this project without his kind encouragement and valuable guidance.
DATE: SIGNATURE:
4
CERTIFICATE OF ORIGINALITY
I hereby declare that the MCA Major Project (KCA-451) titled “Devsearch”
submitted to the IT Department, IMS Noida, which is affiliated with DR.
A.P.J. ABDUL KALAM TECHNICAL UNIVERSITY
LUCKNOW (U.P.) for the partial fulfillment of the degree of Masters of
Computer Application, in Session (2022-24). This has not previously
formed the basis for the award of any other degree, diploma, or other title
from any other University.
PLACE:
DATE:
SIGNATURE:
5
6
1.Project Profile
1.1 Project Definition
What is Devsearch?
Devsearch is a vast platform that changes how software developers work together
on projects. It’s more than just a place to store code; it offers tools for controlling
versions, tracking issues, and reviewing code, which are essential for creating
software today.
Devsearch also has features like forks, pull requests, and merges that help
developers from all over the world work on open-source projects and other
collaborative efforts together.
Techopedia explains the Devsearch Meaning

Understanding Git is crucial for grasping the full Devsearch meaning, as it is the
foundation of Devsearch.
It’s a system that lets developers keep track of and manage changes in their code,
allowing many people to work on the same project at the same time without
messing up each other’s work. This system keeps a detailed record of all changes,
so you can go back to earlier versions if you need to.
Because Git can handle projects of any size efficiently and flexibly, it’s the go-to
choice for developers and is key to making Devsearch a place where people can
work together effectively.
7
1.2 Project Description
DevSearch is an innovative platform designed to streamline the process of
discovering, connecting, and collaborating with developers worldwide. With the
exponential growth of the tech industry, the demand for skilled developers has
never been higher. However, the challenge lies in finding the right talent for
specific projects or roles. DevSearch addresses this challenge by providing a
comprehensive solution that empowers both developers and employers.
At its core, DevSearch functions as a centralized hub where developers can

showcase their skills, projects, and expertise. Through detailed profiles,
developers can highlight their programming languages, frameworks, experience
levels, and previous projects. This allows employers to quickly assess a
developer's suitability for a particular role or project based on their skills and
experience.
One of the key features of DevSearch is its advanced search functionality.

Employers can utilize various filters to narrow down their search and find
developers who meet their specific criteria. Whether it's by programming
language, experience level, location, or project type, employers can easily find the
right talent for their needs.
In addition to traditional search functionality, DevSearch incorporates AI-powered

recommendation algorithms. These algorithms analyze the requirements of a
project or job posting and suggest developers who are the best fit based on their
skills, experience, and past collaborations. This proactive approach not only saves
time for employers but also helps them discover talented developers they may not
have found otherwise.
DevSearch also fosters collaboration and networking within the developer

community. Developers can connect with each other, share knowledge, and
collaborate on projects directly through the platform. This creates opportunities
for skill development, mentorship, and professional growth.
8
Furthermore, DevSearch offers a seamless hiring process, allowing employers to
manage job postings, applications, and interviews all within the platform. From
posting a job opening to extending an offer, employers can efficiently navigate
each step of the hiring process, saving time and resources.
Security and privacy are paramount on DevSearch. The platform employs robust
encryption protocols to safeguard sensitive information and ensure user privacy.
Developers have control over the visibility of their profiles and can choose to
share only relevant information with potential employers.
Overall, DevSearch revolutionizes the way developers are discovered, hired, and
connected within the tech industry. By providing a user-friendly platform with
powerful search and recommendation capabilities, DevSearch empowers both
developers and employers to find the perfect match for their projects and career
opportunities.
9
1.3 Existing System / Work Environment
1.3.1) Existing System:
The existing system of DevSearch comprises a user-friendly platform that

serves as a centralized hub for developers and employers to connect. It
offers features such as user profiles, advanced search functionality,
AI-powered recommendations, collaboration tools, and a streamlined hiring
process.
1. User Profiles: Developers create detailed profiles showcasing their skills,

experience, projects, and expertise. Employers can view these profiles to
assess a developer's suitability for specific roles or projects.
2. Advanced Search: Employers can utilize various filters to narrow down

their search for developers based on criteria such as programming language,
experience level, location, and project type. This helps them find the right
talent efficiently.
3. AI-Powered Recommendations: DevSearch employs recommendation

algorithms that analyze project requirements and suggest developers who
are the best fit based on their skills, experience, and past collaborations.
This proactive approach helps employers discover talented developers
quickly.
4. Collaboration Tools: Developers can connect with each other, share

knowledge, and collaborate on projects directly through the platform. This
fosters a sense of community and provides opportunities for skill
development and mentorship.
5. Streamlined Hiring Process: Employers can manage job postings,

applications, and interviews within the platform. From posting a job
opening to extending an offer, employers can efficiently navigate each step
of the hiring process.
10
6. Security and Privacy: DevSearch prioritizes security and privacy,
employing robust encryption protocols to safeguard sensitive information
and ensure user privacy. Developers have control over the visibility of their
profiles and can choose what information to share with potential employers.
Overall, the existing system of DevSearch provides a comprehensive

solution for discovering, connecting, and collaborating with developers
worldwide. Its user-friendly interface, advanced search capabilities,
AI-powered recommendations, collaboration tools, and streamlined hiring
process make it a valuable resource for both developers and employers in
the tech industry.
11
1.3.2) Work Environment
The work environment at DevSearch is characterized by innovation, collaboration,

and a passion for technology. Here's an overview of what it's like:
1. Innovative Culture: DevSearch fosters an environment that encourages

innovation and creativity. Team members are empowered to think outside the
box, experiment with new ideas, and find innovative solutions to challenges in
the tech industry.
2. Collaborative Atmosphere: Collaboration is at the heart of DevSearch's work

environment. Team members regularly collaborate on projects, share knowledge
and expertise, and support each other to achieve common goals. Whether it's
brainstorming new features, troubleshooting technical issues, or working on
marketing strategies, collaboration is key to success.
3. Tech-Focused: As a tech-driven company, DevSearch places a strong

emphasis on technology and keeps abreast of the latest advancements in the
field. Team members are passionate about technology and are committed to
leveraging it to create impactful solutions for developers and employers.
4. Agile Methodology: DevSearch embraces agile methodologies in its

development processes. Teams work in sprints, allowing for flexibility,
adaptability, and continuous improvement. This approach enables the company
to respond quickly to changes in user needs and market trends.
5. Remote Work Culture: DevSearch embraces remote work culture, providing

flexibility for team members to work from anywhere. Remote work is supported
by robust communication and collaboration tools, ensuring that teams can stay
connected and productive regardless of their location.
6. Diverse and Inclusive: DevSearch values diversity and inclusion and believes
that diverse perspectives lead to better outcomes. The company is committed to
creating an inclusive work environment where all team members feel valued,
respected, and empowered to contribute their unique skills and experiences.
12
7. Continuous Learning: DevSearch encourages continuous learning and
professional development. Team members have access to resources such as
online courses, workshops, and conferences to enhance their skills and stay
updated on industry trends.
Overall, the work environment at DevSearch is dynamic, collaborative, and

tech-focused, where team members are empowered to innovate, collaborate, and
grow professionally.
13
1.4 Problem Statements
The problem statement for DevSearch revolves around the challenges faced
by both developers and employers in the tech industry:
1. Finding the Right Talent:

Employers often struggle to find skilled developers who are the right fit for
their projects or job openings. The process of sourcing, screening, and hiring
talent can be time-consuming and inefficient.
2. Navigating a Fragmented Landscape:

The tech industry is vast and diverse, with developers specializing in various
programming languages, frameworks, and domains. Navigating this
fragmented landscape to find the perfect match for a project or role can be
daunting for employers.
3. Lack of Visibility for Developers:

Many talented developers struggle to gain visibility and showcase their
skills to potential employers. Without a platform to effectively showcase
their expertise, developers may miss out on valuable career opportunities.
4. Tedious Hiring Processes:

Traditional hiring processes can be cumbersome and involve multiple
rounds of interviews, assessments, and negotiations. This not only prolongs
the time to hire but also adds administrative overhead for both employers
and candidates.
5. Limited Networking Opportunities:

Developers may find it challenging to connect with like-minded
professionals, share knowledge, and collaborate on projects outside of their
immediate circles. This limits their ability to expand their network and
collaborate on diverse projects.
14
6. Privacy and Security Concerns:
Both developers and employers are concerned about the security and
privacy of their data when using online platforms for hiring and networking.
Ensuring the confidentiality of sensitive information is paramount to
building trust in such platforms.
In summary, the problem statement for DevSearch revolves around the need for a
comprehensive solution that simplifies the process of discovering, connecting, and
collaborating with developers while addressing concerns related to talent sourcing,
networking, privacy, and security in the tech industry.
15
1.5 Need for New System
Absolutely, let's delve into each need of DevSearch in detail:
1. Efficient Talent Acquisition: DevSearch addresses the need for companies to

efficiently acquire talent by providing a platform where employers can easily find
skilled developers for their projects or teams. The platform streamlines the talent
acquisition process, saving time and resources for employers.
2. Comprehensive Developer Profiles: Developers need a platform to create

comprehensive profiles that showcase their skills, experience, and projects.
DevSearch allows developers to highlight their expertise effectively, increasing
their visibility to potential employers.
3. Tailored Job Matching: Employers seek a platform where they can find
developers whose skills align with their project requirements or job openings.
DevSearch facilitates tailored job matching by allowing employers to search for
developers based on specific criteria such as programming languages, experience
level, and location.
4. Advanced Search Capabilities: DevSearch offers advanced search filters that

enable employers to find developers with precision. Whether it's filtering by
programming language proficiency, years of experience, or project type, the
platform provides robust search functionality to meet employers' needs.
5. Proactive Talent Recommendations: DevSearch's recommendation algorithms

analyze project requirements and developer profiles to suggest suitable candidates
to employers. This proactive approach helps employers discover talented
developers they may not have found through traditional search methods.
6. Collaboration Tools: Developers require tools to connect, communicate, and

collaborate on projects with other developers. DevSearch provides collaboration
tools such as messaging, project sharing, and version control integration to
facilitate seamless teamwork.
16
7. Streamlined Hiring Process: DevSearch streamlines the hiring process by
providing tools for managing job postings, applications, and interviews within one
centralized platform. Employers can track candidate progress, schedule interviews,
and make hiring decisions efficiently.
8. Remote Work Support: With the increasing prevalence of remote work,

DevSearch supports remote collaboration by providing a platform where
developers can work from anywhere and collaborate effectively with team
members.
9. Continuous Learning Resources: DevSearch offers a wide range of resources

such as online courses, tutorials, and articles to support developers in their
continuous learning and skill development journey. Developers can stay updated on
the latest technologies and trends to enhance their expertise.
10. Networking Opportunities: DevSearch facilitates networking opportunities

for developers to connect with peers, mentors, and potential collaborators within
the tech community. Through forums, discussions, and events, developers can
expand their professional network and build valuable relationships.
11. Privacy and Data Security: Both developers and employers require assurance
that their data is secure and their privacy is protected when using the platform for
hiring and networking. DevSearch prioritizes data security and implements robust
measures to safeguard user information.
12. Feedback and Review Mechanism: DevSearch incorporates a feedback and

review system where employers can provide feedback on developers they have
worked with, helping to build trust and credibility within the community.
13. Diverse Talent Pool: Employers value access to a diverse talent pool with
developers from different backgrounds, experiences, and perspectives. DevSearch
promotes diversity and inclusion, ensuring that employers have access to a wide
range of talented developers.
17
14. Community Engagement: DevSearch fosters a sense of community by
encouraging engagement through forums, discussions, and events within the
platform. Developers can exchange ideas, seek advice, and collaborate on projects,
creating a vibrant and supportive community.
15. Career Growth Opportunities: Developers seek opportunities for career

growth, advancement, and professional development. DevSearch provides access
to job openings, mentorship programs, and learning resources to help developers
achieve their career goals and aspirations.
18
1.6 Proposed System & Features
1.6.1) Proposed System:
The proposed system of DevSearch builds upon its existing features while
introducing enhancements to further streamline the process of discovering,
connecting, and collaborating with developers. Here's an outline of the proposed
system:
1. Enhanced User Profiles: Developers can create more comprehensive profiles,

including additional sections for certifications, awards, and testimonials from
previous employers or clients.
This allows developers to showcase their expertise and credibility more
effectively.
2. Improved Search Functionality: The search functionality is enhanced with

more advanced filters and sorting options, allowing employers to find developers
with even greater precision.
Employers can also save search criteria for future use and receive notifications
when new developers matching their criteria join the platform.
3. AI-Powered Candidate Matching: DevSearch incorporates advanced AI

algorithms to analyze job postings and developer profiles, providing employers
with highly accurate candidate recommendations.
Employers can receive personalized suggestions based on the specific
requirements of their projects or job openings.
4. Integrated Coding Assessments: The platform integrates coding assessment

tools, allowing employers to evaluate candidates' technical skills directly within
DevSearch.
This streamlines the screening process and provides employers with valuable
insights into candidates' coding abilities.
19
5. Virtual Collaboration Spaces: DevSearch introduces virtual collaboration
spaces where developers can work together on projects in real-time. These spaces
include features such as code editors, video conferencing, and task management
tools, enabling seamless collaboration regardless of geographical location.
6. Automated Interview Scheduling: DevSearch automates the interview

scheduling process by allowing employers to set their availability and preferences
directly within the platform.
Candidates can then select a time slot that works for them, eliminating the
back-and-forth communication typically involved in scheduling interviews.
7. Enhanced Privacy Controls: Developers have greater control over the

visibility of their profiles, allowing them to customize who can view certain
sections of their profile.
This ensures that developers can maintain their privacy while still showcasing
their skills to potential employers.
8. Community Q&A Forum: DevSearch introduces a community Q&A forum

where developers can ask questions, seek advice, and share knowledge with their
peers.
This fosters a sense of community and encourages collaboration and learning
among developers.
9. Integrated Learning Platform: DevSearch integrates a learning platform

with access to a curated library of educational resources, including tutorials,
articles, and courses.
Developers can easily access relevant learning materials to enhance their skills
and stay updated on the latest technologies.
10. Enhanced Analytics Dashboard: Employers have access to an enhanced

analytics dashboard that provides insights into the performance of their job
postings, candidate engagement, and hiring metrics.
This allows employers to track the effectiveness of their recruitment efforts and
make data-driven decisions.
20
Overall, the proposed system of DevSearch aims to provide an even more
seamless and efficient experience for both developers and employers, leveraging
advanced technology to facilitate talent discovery, collaboration, and professional
growth within the tech industry.
21
1.6.2) Features of Devsearch:
Certainly! Let's dive into the features of DevSearch in more detail:
1. User Profiles: Developers can create comprehensive profiles showcasing their

skills, experience, education, certifications, and projects. They can also include a
portfolio of their work, GitHub repositories, and links to their professional social
media profiles.
2. Advanced Search: Employers can use advanced search filters to find

developers based on specific criteria such as programming languages, frameworks,
experience level, location, availability, and project type. They can save search
criteria for future use and receive notifications when new developers match their
requirements.
3. AI-Powered Recommendations: DevSearch's recommendation algorithms

analyze project requirements and developer profiles to suggest the most suitable
candidates to employers. Recommendations are personalized based on the
employer's preferences and the developer's skills, experience, and past
collaborations.
4. Collaboration Tools: DevSearch provides collaboration tools such as

messaging, file sharing, version control integration (e.g., GitHub), and project
management features. Developers can communicate with each other, share code
snippets, collaborate on projects, and track progress within the platform.
5. Streamlined Hiring Process: Employers can manage the entire hiring process
within DevSearch, from posting job openings to extending offers. They can track
candidate applications, schedule interviews, and communicate with candidates
directly through the platform, streamlining the hiring workflow and saving time.
6. Remote Work Support: DevSearch supports remote work by providing tools

for virtual collaboration, communication, and project management. Developers can
work from anywhere and collaborate effectively with team members regardless of
their location.
7. Continuous Learning Resources: DevSearch offers a library of educational

22
resources such as online courses, tutorials, articles, and webinars to support
developers in their continuous learning and skill development.
Developers can access relevant learning materials to enhance their skills and stay
updated on the latest technologies.
8. Community Engagement: DevSearch fosters a sense of community by

providing forums, discussion boards, and virtual events where developers can
connect, ask questions, share knowledge, and network with their peers. Community
engagement features encourage collaboration, mentorship, and professional growth
within the developer community.
9. Privacy and Security: DevSearch prioritizes user privacy and security by

implementing robust encryption protocols and data protection measures.
Developers have control over the visibility of their profiles and can choose which
information to share with employers. The platform complies with data privacy
regulations to ensure the confidentiality and integrity of user data.
10. Feedback and Review Mechanism: Employers can provide feedback and
ratings on developers they have worked with, helping to build trust and credibility
within the community. Reviews and ratings contribute to developers' reputations on
the platform and help employers make informed hiring decisions.
These features collectively make DevSearch a comprehensive platform for

developers and employers to connect, collaborate, and succeed in the tech industry.
23
1.7 Scope
The scope of DevSearch encompasses various aspects of the tech

industry, aiming to address the needs of developers, employers, and the
broader developer community. Here's an overview of its scope:
1. Talent Discovery and Recruitment: DevSearch facilitates the process of

discovering and recruiting talented developers for projects, job openings, or
freelance opportunities. It provides employers with tools to search for developers
based on specific criteria and receive recommendations tailored to their needs.
2. Developer Profiles and Portfolios: DevSearch allows developers to create

comprehensive profiles showcasing their skills, experience, projects, and
achievements. They can also build portfolios to highlight their work, GitHub
repositories, and contributions to open-source projects.
3. Collaboration and Networking: DevSearch fosters collaboration and

networking among developers by providing communication tools, collaboration
spaces, and community forums. Developers can connect with peers, share
knowledge, collaborate on projects, and participate in discussions within the
platform.
4. Continuous Learning and Skill Development: DevSearch offers a range of

educational resources such as online courses, tutorials, articles, and webinars to
support developers in their continuous learning and skill development journey.
Developers can access relevant learning materials to enhance their skills and stay
updated on the latest technologies.
5. Remote Work Support: DevSearch supports remote work by providing virtual

collaboration tools and communication features. Developers can work from
anywhere and collaborate effectively with team members, regardless of their
geographical location.
6. Streamlined Hiring Process: DevSearch streamlines the hiring process for

employers by offering tools for managing job postings, applications, interviews,
and candidate evaluations within one centralized platform.
24
This saves time and resources for employers and improves the overall efficiency
of the hiring workflow.
7. Privacy and Security: DevSearch prioritizes user privacy and security by

implementing robust encryption protocols, data protection measures, and privacy
controls. Developers have control over the visibility of their profiles and can
choose which information to share with employers, ensuring the confidentiality
and integrity of their data.
8. Feedback and Reviews: DevSearch incorporates a feedback and review

mechanism where employers can provide feedback and ratings on developers they
have worked with. Reviews and ratings contribute to developers' reputations on
the platform and help employers make informed hiring decisions.
Overall, the scope of DevSearch is to provide a comprehensive platform that

connects developers with opportunities, facilitates collaboration and learning,
streamlines the hiring process for employers, and fosters a vibrant and supportive
community within the tech industry.
25
1.8 Outcomes
The outcome of DevSearch encompasses various benefits and impacts

for developers, employers, and the tech industry as a whole. Here's a
detailed overview of the outcomes:
1. For Developers:
- *Increased Visibility*: DevSearch provides developers with a platform to

showcase their skills, projects, and expertise, increasing their visibility to potential
employers.
- Enhanced Opportunities: Developers gain access to a wider range of job

opportunities, freelance projects, and collaboration opportunities within the tech
community.
- Continuous Learning: DevSearch offers a library of educational resources and

networking opportunities to support developers in their continuous learning and
skill development journey.
- Career Growth: Developers can leverage DevSearch to connect with mentors,

receive feedback on their work, and access resources for career advancement and
professional growth.
2. For Employers:
- Efficient Talent Acquisition: Employers can efficiently discover, evaluate, and

recruit skilled developers for their projects or job openings, reducing time-to-hire
and improving hiring efficiency.
- Access to Diverse Talent Pool: DevSearch provides access to a diverse talent

pool with developers from different backgrounds, experiences, and perspectives,
enabling employers to build diverse and inclusive teams.
26
- Streamlined Hiring Process: DevSearch streamlines the hiring process by
offering tools for managing job postings, applications, interviews, and candidate
evaluations within one centralized platform.
- Quality Candidates: Employers receive recommendations and insights on the

most suitable candidates for their projects or job openings, helping them identify
and hire top talent effectively.
3. For the Tech Industry:
- Improved Collaboration: DevSearch fosters collaboration and knowledge

sharing among developers, leading to increased innovation, productivity, and quality
of work within the tech industry.
- Enhanced Skills Development: DevSearch offers a range of educational

resources and networking opportunities to support developers in their continuous
learning and skill development journey, contributing to the overall skill
development of the tech workforce.
- Efficient Talent Marketplace: DevSearch creates a more efficient and

transparent marketplace for talent, connecting developers with opportunities and
employers with skilled professionals, thereby driving growth and innovation in the
tech industry.
- Positive Community Impact: DevSearch contributes to building a vibrant and

supportive community within the tech industry, where developers can connect,
collaborate, and grow together, leading to a positive impact on the overall
ecosystem.
Overall, the outcome of DevSearch is to empower developers, streamline the hiring

process for employers, and contribute to the growth and innovation of the tech
industry through efficient talent discovery, collaboration, and skill development.
27
1.9 Tools and technology used:-
For Frontend
1) HTML:-
● HTML (HyperText Markup Language) is the standard language used to create
and structure content on the web.
● It consists of a series of elements, represented by tags, that define different
parts of a webpage, such as headings, paragraphs, links, images, and other
multimedia.
● HTML tags are written within angle brackets, like <html>, <head>, <body>,
<p>, and <a>. HTML provides the skeleton of a webpage, enabling browsers
to display text, images, and interactive forms in a structured format.
● Each HTML document begins with a <!DOCTYPE html> declaration,
followed by an <html> element that encompasses the entire content.
● The <head> section contains metadata, links to stylesheets, and scripts, while
the <body> section includes the actual content displayed to users.
● HTML works in conjunction with CSS (Cascading Style Sheets) for styling
and JavaScript for interactivity, forming the core technologies for web
development.
28
2) CSS:-
● CSS, or Cascading Style Sheets, is a stylesheet language used to describe the
presentation of a document written in HTML or XML.
● CSS defines how elements should be displayed on screen, paper, or in other
media.
● It enables developers to separate content from design, providing a more
flexible and efficient method for designing web pages.
● CSS allows for the styling of multiple elements simultaneously, promoting
consistency across a website.
● It includes features for layout, color, font, spacing, and responsive design,
ensuring that web pages look good on various devices and screen sizes.
● By using selectors and properties, developers can target HTML elements and
apply specific styles to them.
● CSS can be embedded within HTML documents, included as an external file,
or written inline within HTML tags.
● Its cascading nature means that styles can be applied hierarchically, with more
specific rules overriding more general ones.
29
3) Javascript:-
● JavaScript is a versatile, high-level programming language primarily used for
creating and enhancing interactive elements on websites.
● As a core technology of the World Wide Web, alongside HTML and CSS,
JavaScript enables dynamic content that can respond to user actions, such as
form validations, animated graphics, interactive maps, and real-time updates.
● Initially developed by Netscape in 1995, JavaScript has evolved significantly
and is now an essential tool for front-end development, often employed in
conjunction with frameworks like React, Angular, and Vue.js.
● Additionally, with the advent of Node.js, JavaScript can also be used for
server-side programming, making it a full-stack language.
● Its syntax is similar to Java and C++, which helps in learning other
programming languages.
● JavaScript's versatility and widespread adoption make it a fundamental skill
for web developers, facilitating the creation of modern, responsive, and
user-friendly web applications.
30
For Backend
Django:-
● Django is a high-level Python web framework designed to facilitate the rapid

creation of robust and scalable web applications.
● It promotes the principle of "Don't Repeat Yourself" (DRY), enabling
developers to focus on writing unique code by providing a wealth of built-in
features.
● Django handles common web development tasks such as database operations,
user authentication, and URL routing, reducing the need for manual coding.
● It includes an object-relational mapper (ORM) for database interactions, a
powerful templating engine, and an intuitive admin interface for managing
application data. Additionally, Django emphasizes security, incorporating
protections against common web vulnerabilities like SQL injection and
cross-site scripting (XSS).
● Its modular architecture and extensive documentation make it suitable for both
beginners and experienced developers, supporting projects ranging from
simple websites to complex, enterprise-level applications.
● Overall, Django streamlines web development while maintaining flexibility
and scalability.
31
Python:-
● Python is a high-level, interpreted programming language known for its

simplicity, versatility, and readability. Created by Guido van Rossum and first
released in 1991, Python has since become one of the most popular
programming languages worldwide.
● Its syntax is clean and easy to understand, making it an excellent choice for
beginners and experienced developers alike.
● Python's versatility is evident in its wide range of applications. It is commonly
used in web development, with frameworks like Django and Flask enabling
developers to build robust and scalable web applications.
● Additionally, Python's extensive libraries, such as NumPy, pandas, and
matplotlib, make it a popular choice for data analysis and scientific
computing. Its simplicity and ease of use also make it suitable for tasks like
automation, scripting, and rapid prototyping.
● One of Python's key strengths is its extensive standard library, which provides
modules and functions for performing various tasks without the need for
additional installations.
● Moreover, Python's active community continually develops third-party
packages that extend its capabilities even further, covering areas such as
machine learning, natural language processing, and game development.
● Python's readability stems from its use of indentation to define code blocks,
rather than relying on curly braces or keywords.
32
● This encourages a clean, consistent coding style and reduces the likelihood of
syntax errors. Furthermore, Python's dynamic typing system allows variables
to be assigned without specifying their data types explicitly, enhancing code
flexibility and reducing verbosity.
33
1.10 Project Plan
- Creating a project plan for DevSearch involves outlining the key

phases, tasks, timelines, resources, and milestones involved in the
development and launch of the platform. Here's a high-level project
plan for DevSearch:
- 1. Project Initiation Phase:

- Define project objectives, scope, and requirements.
- Identify key stakeholders and establish communication channels.
- Develop a project charter outlining project goals, timelines, and
responsibilities.
- Conduct initial market research and competitor analysis to understand the
landscape.
2. Planning Phase:
- Develop a detailed project plan outlining tasks, dependencies, timelines,
and resources required for each phase.
- Identify and prioritize features and functionalities based on user needs and
market demand.
- Define technical specifications, architecture, and technology stack for the
platform.
- Establish project milestones and deliverables.
3. Design and Prototyping Phase:

- Design user interface mockups, wireframes, and prototypes based on the
defined requirements.
- Gather feedback from stakeholders and iterate on designs to ensure
usability and user satisfaction.
- Develop a design style guide and branding elements for the platform.
- Finalize the visual design and user experience of the platform.
34
4. Development Phase:
- Develop the backend infrastructure, databases, and APIs required for the
platform.
- Implement frontend components and user interfaces based on the approved
designs.
- Integrate third-party services and tools as needed, such as AI algorithms,
collaboration tools, and communication platforms.
- Conduct regular code reviews, testing, and debugging to ensure quality and
stability.
5. Testing and Quality Assurance Phase:

- Develop test cases and scenarios to validate the functionality, performance,
and security of the platform.
- Conduct comprehensive testing including unit testing, integration testing,
regression testing, and user acceptance testing.
- Address any bugs, issues, or performance bottlenecks identified during
testing.
- Ensure compliance with data privacy regulations and security standards.
6. Deployment Phase:
- Prepare for the deployment of the platform to production servers or cloud
infrastructure.
- Configure deployment pipelines, continuous integration, and automated
deployment processes.
- Perform final checks and validations to ensure a smooth deployment
process.
- Monitor system performance and user feedback post-deployment, and
address any issues as they arise.
7. Launch and Marketing Phase:

- Develop a marketing and communication strategy to promote the launch of
DevSearch.
- Create marketing materials such as website content, blog posts, social
media campaigns, and press releases.
- Engage with potential users, partners, and industry influencers to generate
buzz and interest in the platform.
35
- Monitor user acquisition, engagement, and feedback post-launch, and
iterate on marketing strategies as needed.
8. Post-Launch Maintenance and Support Phase:

- Provide ongoing maintenance, updates, and support for the platform to
address user feedback, bug fixes, and feature enhancements.
- Monitor system performance, security, and scalability, and optimize as
needed to ensure a seamless user experience.
- Continuously iterate on the platform based on user feedback, market
trends, and technological advancements to keep DevSearch competitive and
relevant in the long term.
Throughout the project lifecycle, regular communication, collaboration, and

coordination among team members, stakeholders, and external partners are
essential to ensure the successful development and launch of DevSearch.
Additionally, flexibility and adaptability to changes in requirements, priorities,
and market dynamics are key to overcoming challenges and achieving project
objectives.
36
2. Requirement Analysis
2.1 Feasibility Study
1. Market Demand:- Analyze the demand for developer-focused search

platforms. - Identify target demographics within the developer community.
2. Competition Analysis:- Evaluate existing developer search tools and
platforms. - Assess their strengths, weaknesses, and market penetration. -
Identify opportunities for differentiation and market positioning.
3. User Needs and Requirements:- Conduct surveys and interviews to
understand developers' pain points and preferences. - Determine the key
features and functionalities required to meet user needs effectively.
4. Technological Feasibility:- Assess the technical requirements for developing
and maintaining DevSearch. - Determine the feasibility of implementing
desired features within the chosen technological stack. - Evaluate scalability,
performance, and compatibility with existing systems and tools.
5. Cost Analysis:- Estimate the initial development costs, including software
development, infrastructure, and staffing. - Project ongoing operational
expenses, such as maintenance, hosting, and support. - Compare costs against
potential revenue streams or funding sources.
6. Usability and User Experience:- Design and conduct usability tests to
evaluate the user interface and overall user experience. - Incorporate feedback
to optimize navigation, search functionality, and accessibility.
7. Security and Privacy Considerations:- Identify potential security threats and
vulnerabilities. - Implement robust security measures to protect user data and
prevent unauthorized access. - Ensure compliance with relevant privacy
regulations and standards.
37
8. Scalability and Performance:- Assess the platform's ability to handle
increasing user traffic and data volumes. - Implement scalable architecture and
performance optimization techniques. - Conduct stress tests to identify
potential bottlenecks and performance limitations.
9. Pilot Testing and Feedback:- Conduct pilot tests with a small group of users
to gather feedback and iterate on the platform. - Use feedback to refine
features, address usability issues, and improve overall satisfaction.
Conclusion:- Based on the findings, determine the feasibility of developing and

launching DevSearch. - Identify potential risks and mitigation strategies. - Make
recommendations for further development and investment based on the study's
results.
38
2.2 Users of the System:
Devsearch is a web application designed to connect developers with

various projects, job opportunities, and other developers for networking
and collaboration. Users of Devsearch typically fall into several
categories:
1. Individual Developers:
Freelancers: Looking for new projects and clients to work with. They use
Devsearch to find job postings and project opportunities that match their skill sets.
Job Seekers: Developers seeking full-time, part-time, or contract positions. They

use the platform to search for job listings, submit applications, and network with
potential employers.
Learners: New or junior developers aiming to gain experience and build their
portfolios. They use Devsearch to find mentorship opportunities, open-source
projects to contribute to, and learning resources.
2. Employers and Recruiters:
Tech Companies: Businesses in need of software development talent. They use

Devsearch to post job openings, browse developer profiles, and recruit candidates
for various roles.
Recruitment Agencies: Agencies specializing in tech recruitment. They use the

platform to find suitable candidates for their clients' needs.
3. Project Owners and Managers:
Startup Founders: Entrepreneurs looking to build a tech product. They use

Devsearch to find developers with the necessary skills to bring their ideas to life.
Project Managers: Individuals overseeing development projects. They use the

platform to recruit team members, manage collaborations, and ensure project
milestones are met.
39
4. Community Builders and Educators:
Mentors: Experienced developers who offer guidance and support to less

experienced developers. They use Devsearch to connect with mentees and
contribute to the developer community.
Educators: Instructors and trainers who provide coding boot camps, courses, and
workshops. They use the platform to reach potential students and collaborate on
educational content.
40
2.3 Modules
Sure, here's a detailed breakdown of the modules that could be part of

DevSearch:
1. User Authentication and Profile Management:

This module handles user registration, login, and profile management
functionalities. It ensures secure authentication and allows users to update their
profiles, including personal information, preferences, and settings.
2. Search Engine:
The core functionality of DevSearch, this module enables users to search for
programming languages, frameworks, libraries, tools, documentation, tutorials,
articles, and discussions. It utilizes search algorithms and indexing techniques
to provide relevant and accurate search results.
3. Trending Topics and Insights:

This module tracks and analyzes trending topics, discussions, and technologies
within the developer community. It presents insights and analytics to users,
helping them stay updated on the latest trends and developments in the
programming world.
4. Documentation Repository:
DevSearch maintains a comprehensive repository of documentation for various
programming languages, frameworks, and libraries. This module organizes and
categorizes documentation, making it easily accessible to users for reference
and learning purposes.
5. Community Interaction and Collaboration:

This module facilitates community interaction, allowing users to engage in
discussions, ask questions, share insights, and provide feedback. It includes
features such as forums, comment sections, chat functionalities, and social
networking elements to foster collaboration and knowledge sharing among
developers.
6. Recommendation Engine:
Based on user preferences, search history, and behavior, this module provides
personalized recommendations for programming tools, resources, tutorials, and
articles. It utilizes machine learning algorithms and data analysis techniques to
suggest relevant content and enhance the user experience.
41
7. Integration Support with External Tools and Platforms:
DevSearch integrates with other developer tools and platforms, such as IDEs,
version control systems, project management tools, and online repositories. This
module ensures seamless interoperability and allows users to access relevant
information from their preferred tools within the DevSearch ecosystem.
8. Admin Panel and Content Management:

This module is responsible for managing user-generated content, moderating
discussions, and administering the platform. It includes functionalities for
content moderation, user management, analytics, and reporting to ensure the
smooth operation of the platform.
9. Notifications and Alerts:

DevSearch sends notifications and alerts to users for various activities, such as
new discussions, replies to their posts, trending topics, and updates related to
their interests. This module enhances user engagement and keeps users
informed about relevant events within the platform.
10. Analytics and Insights: This module collects and analyzes data related to
user behavior, search patterns, engagement metrics, and platform usage. It
generates insights and reports to help administrators understand user
preferences, identify trends, and make data-driven decisions to improve the
platform.
These modules collectively form the foundation of DevSearch, providing a

comprehensive and user-centric platform for developers to search, discover, and
collaborate on programming-related topics and resources.
42
2.4 Hardware & Software Requirements
Hardware requirements:
● Processor: Minimum Intel core i3

● RAM: Minimum 4GB
● Hard-disk: Minimum 8GB
● Connectivity: Internet connectivity is required
Software requirements:
● VS Code
● Python
● TensorFlow
● NumPy
● IDE (Integrated Development Environment)
● Version Control System (e.g., Git)
● Text Editors (for Documentation)
43
3) Design
3.1) Diagram
3.1.1) DFD
44
3.1.2) ER Diagram
45
4) Implementation:
4.1) Code:-
4.1.1) HTML Code:-
main.html
<!DOCTYPE html>
{% load static %}
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />


<link rel="shortcut icon" href="images/favicon.ico" type="image/x-icon" />

<link
rel="stylesheet"
href="https://cdn.iconmonstr.com/1.3.0/css/iconmonstr-iconic-font.min.css"
/>

<link rel="stylesheet" href="{% static 'uikit/styles/uikit.css' %}" />

<link rel="stylesheet" href="{% static 'styles/app.css' %}" />
<title>DevSearch - Connect with Developers!</title>

</head>
<body>

<header class="header">
<div class="container container--narrow">
<a href="{% url 'profiles' %}" class="header__logo">
46
<img src="{% static 'images/logo.svg' %}" alt="DevSearch Logo" />
</a>
<nav class="header__nav">
<input type="checkbox" id="responsive-menu" />
<label for="responsive-menu" class="toggle-menu">
<span>Menu</span>
<div class="toggle-menu__lines"></div>
</label>
<ul class="header__menu">
<li class="header__menuItem"><a href="{% url 'profiles'
%}">Developers</a></li>
<li class="header__menuItem"><a href="{% url 'projects'
%}">Projects</a></li>
{% if request.user.is_authenticated %}
<li class="header__menuItem"><a href="{% url 'account'
%}">Account</a></li>
<li class="header__menuItem"><a href="{% url 'inbox' %}">Inbox</a></li>
<li class="header__menuItem"><a href="{% url 'logout' %}" class="btn

btn--sub">Logout</a></li>
{% else %}
<li class="header__menuItem"><a href="{% url 'login' %}" class="btn
btn--sub">Login/Sign Up</a></li>
{% endif %}
</ul>
</nav>
</div>
</header>
{% if messages %}
47
{% for message in messages %}
<div class="alert alert--{{messgae.tags}}">
<p class="alert__message">{{message}}</p>
<button class="alert__close">x</button>
</div>
{% endfor %}
{% endif %}
{% block content %} {% endblock content %}
<script src="{% static 'uikit/app.js' %}"></script>

<script src="{% static 'js/main.js' %}"></script>
</body>
</html>
48
index.html
<!DOCTYPE html>
<html lang="en">
<head>


<link rel="stylesheet"
href="https://cdn.iconmonstr.com/1.3.0/css/iconmonstr-iconic-font.min.css" />

<link rel="stylesheet" href="uikit/styles/uikit.css" />
<link rel="stylesheet" href="styles/app.css" />

</head>
<body>
<a href="/" class="header__logo">
<img src="images/logo.svg" alt="DevSearch Logo" />
</a>
49
<span>Menu</span>
</label>
<li class="header__menuItem"><a href="index.html">Developers</a></li>
<li class="header__menuItem"><a href="projects.html">Projects</a></li>
<li class="header__menuItem"><a href="inbox.html">Inbox</a></li>
<li class="header__menuItem"><a href="account.html">My
Account</a></li>
<li class="header__menuItem"><a href="login.html" class="btn
</ul>
</nav>
</div>
</header>


<main class="home">
<section class="hero-section text-center">
<div class="hero-section__box">
<h2>CONNECT WITH <span>DEVELOPERS</span></h2>
<h2>FROM AROUND THE WORLD</h2>
</div>
<div class="hero-section__search">
<form class="form" action="#" method="get">
<div class="form__field">
<label for="formInput#search">Search Developers </label>
<input class="input input--text" id="formInput#search" type="text"
name="text"
placeholder="Search by developer name" />
</div>
50
<input class="btn btn--sub btn--lg" type="submit" value="Search" />
</form>
</div>
</div>
</section>

<section class="devlist">
<div class="container">
<div class="grid grid--three">
<div class="column card">
<div class="dev">
<a href="/profile.html" class="card__body">
<div class="dev__profile">
<img class="avatar avatar--md"
src="https://avatars.githubusercontent.com/u/22437186" alt="image" />
<div class="dev__meta">
<h3>Shahriar P. Shuvo</h3>
<h5>FullStack Web Designer & Developer</h5>
</div>
</div>
<p class="dev__info">
Lorem ipsum dolor sit, amet consectetur adipisicing elit. Cupiditate,
ducimus inventore! Sunt,
veniam veritatis? Veritatis placeat, deleniti iure tempore veniam
perspiciatis, soluta cupiditate
animi, exercitationem molestias nam doloremque architecto odit.
</p>
<div class="dev__skills">
<span class="tag tag--pill tag--main">
<small>JavaScript</small>
</span>
<small>React</small>
</span>
51
<small>SCSS</small>
</span>
<small>Nodejs</small>
</span>
<small>Express</small>
</span>
<small>GraphQL</small>
</span>
</div>
</a>
</div>
</div>
<div class="dev">
<h3>Cody Seibert</h3>
<h5>React Developer, Coding Youtuber</h5>
</div>
</div>
52
</p>
<small>Elixir</small>
</span>

<small>F#</small>
</span>
<small>.NET</small>
</span>
</div>
</a>
</div>
</div>
<div class="dev">

<h3>Dennis Ivy</h3>
<h5>Python & Django Developer</h5>
</div>
</div>
53
</p>
<small>Python</small>
</span>
<small>Django</small>
</span>
<small>Rest API</small>
</span>
</div>
</a>
</div>
</div>
<div class="dev">

</div>
</div>
54
</p>

</span>
</span>
<small>SCSS</small>
</span>
</div>
</a>
</div>
</div>
<div class="dev">
</div>
</div>
55
</p>
</span>

</span>
<small>SCSS</small>
</span>
</div>
</a>
</div>
</div>
<div class="dev">
</div>
</div>
56
</p>
</span>
</span>

<small>SCSS</small>
</span>
</div>
</a>
</div>
</div>
</div>
</div>
</section>
<div class="pagination">
<ul class="container">
<li><a href="#" class="btn btn--disabled">❮ Prev</a></li>
<li><a href="#" class="btn btn--sub">01</a></li>
<li><a href="#" class="btn">02</a></li>
<li><a href="#" class="btn">Next ❯</a></li>
</ul>
57
</div>
</main>
</body>
</html>
login.html
<!DOCTYPE html>
<html lang="en">
<body>
<div class="auth">
<div class="card">
<div class="auth__header text-center">
<a href="/">
<img src="images/icon.svg" alt="icon" />
</a>
<h3>Account Login</h3>
<p>Hello Developer, Welcome Back!</p>
</div>
<form action="#" class="form auth__form">


<label for="formInput#text">Username: </label>
<input
class="input input--text"
id="formInput#text"
58
type="text"
name="username"
placeholder="Enter your username..."
/>
</div>


<label for="formInput#password">Password: </label>
<input
class="input input--password"
id="formInput#passowrd"
type="password"
name="password"
placeholder="••••••••"
/>
</div>
<div class="auth__actions">
<input class="btn btn--sub btn--lg" type="submit" value="Log In" />
<a href="forgetpassword.html">Forget Password?</a>
</div>
</form>
<div class="auth__alternative">
<p>Don’t have an Account?</p>
<a href="signup.html">Sign Up</a>
</div>
</div>
</div>
</body>
</html>
59
profile.html
<!DOCTYPE html>
<html lang="en">
<head>


<link rel="stylesheet"
href="https://cdn.iconmonstr.com/1.3.0/css/iconmonstr-iconic-font.min.css" />

<link rel="stylesheet" href="uikit/styles/uikit.css" />
<link rel="stylesheet" href="styles/app.css" />

</head>
<body>
60
<a href="/" class="header__logo">
<img src="images/logo.svg" alt="DevSearch Logo" />
</a>
<span>Menu</span>
</label>
<li class="header__menuItem"><a href="index.html">Developers</a></li>
<li class="header__menuItem"><a href="projects.html">Projects</a></li>
<li class="header__menuItem"><a href="inbox.html">Inbox</a></li>

<li class="header__menuItem"><a href="account.html">My
Account</a></li>
<li class="header__menuItem"><a href="login.html" class="btn
</ul>
</nav>
</div>
</header>


<main class="profile my-md">
<div class="container">
<div class="layout">
<div class="column column--1of3">
<div class="card text-center">
<div class="card__body dev">
<img class="avatar avatar--xl"
src="https://avatars.githubusercontent.com/u/33843378" />
<h2 class="dev__name">Dennis Ivanov</h2>
<p class="dev__title">Expirance FullStack Developer, Youtuber and
Instructor</p>
<p class="dev__location">Based in Florida, USA</p>
<ul class="dev__social">
<li>
61
<a title="Github" href="#" target="_blank"><i class="im
im-github"></i></a>
</li>
<li>
<a title="Stackoverflow" href="#" target="_blank"><i class="im
im-stackoverflow"></i></a>
</li>
<li>
<a title="Twitter" href="#" target="_blank"><i class="im
im-twitter"></i></a>
</li>
<li>
<a title="LinkedIn" href="#" target="_blank"><i class="im
im-linkedin"></i></a>
</li>
<li>
<a title="Personal Website" href="#" target="_blank"><i class="im
im-globe"></i></a>
</li>
</ul>
<a href="#" class="btn btn--sub btn--lg">Send Message </a>
</div>
</div>
</div>
<div class="column column--2of3">
<div class="devInfo">
<h3 class="devInfo__title">About Me</h3>
<p class="devInfo__about">
Lorem, ipsum dolor sit amet consectetur adipisicing elit. Ex illum ipsum
iusto consequatur. Totam,
dolorum fugiat, debitis facere illo nostrum nesciunt maxime, deserunt enim
voluptatibus modi natus velit
voluptatum. Dicta eritatis exercitationem ut quos a placeat obcaecati?
Architecto illum!
<br />
Amet consectetur adipisicing elit. Veritatis exercitationem ut quos a placeat
obcaecati? Architecto
illum, atque delectus nemo dolorem inventore ab facilis? Dolor placeat vel
delectus ipsam ullam.
62
</p>
</div>
<h3 class="devInfo__title">Skills</h3>
<div class="devInfo__skills">
<div class="devSkill">
<h4 class="devSkill__title">JavaScript</h4>
<p class="devSkill__info">
Lorem ipsum dolor sit amet consectetur adipisicing elit. Recusandae
neque voluptatum ut? Quaerat, ea
cumque! Dolorum provident esse molestias commodi odit sapiente quod
quasi corrupti obcaecati? Nobis
ex temporibus quaerat!
</p>
</div>
<h4 class="devSkill__title">React</h4>
Smet consectetur adipisicing elit. Omnis, nihil? Accusamus aspernatur
aut debitis vitae quaerat
nihil fugiat, doloremque nesciunt alias pariatur maxime unde, nam saepe
laborum at odit labore.
</p>
</div>
<h4 class="devSkill__title">Express(Nodejs)</h4>
Auae error deleniti aperiam enim nisi nesciunt, ratione eveniet eos fuga
ad recusandae mollitia!
Facere earum, distinctio nihil recusandae ipsum nesciunt. Possimus, ex.
Officia maxime nihil
inventore cum tenetur! Veritatis sapiente libero ducimus nesciunt itaque,
placeat inventore sint
blanditiis?
</p>
</div>
<h3 class="devInfo__subtitle">Other Skills</h3>

<div class="devInfo__otherSkills">
63
<span class="tag tag--pill tag--sub tag--lg">
<small>Figma</small>
</span>
<small>Vuejs</small>
</span>
<small>REST API</small>
</span>
</span>
<small>TypeScript</small>
</span>
<small>Webpack</small>
</span>
<small>NextJS</small>
</span>
<small>Postgres</small>
</span>
<small>MongoDB</small>
</span>
</div>
</div>
</div>
<h3 class="devInfo__title">Projects</h3>
<div class="grid grid--two">
<div class="column">
<div class="card project">
<a href="single-project.html" class="project">
<img class="project__thumbnail" src="images/project-b.png"
alt="project thumbnail" />
64
<div class="card__body">
<h3 class="project__title">DevSearch UI Design</h3>
<p><a class="project__author" href="profile.html">By Shahriar P.
Shuvo</a></p>
<p class="project--rating">
<span style="font-weight: bold;">92%</span> Postitive
Feedback (62 Votes)
</p>
<div class="project__tags">
</span>
</span>
</span>
</div>
</div>
</a>
</div>
</div>
<img class="project__thumbnail" src="images/project-c.png"
<h3 class="project__title">Another Landing Page</h3>
<p><a class="project__author" href="profile.html">By Dennis
Ivanov</a></p>
Feedback (18 Votes)
</p>
65
</span>
</span>
</span>
</div>
</div>
</a>
</div>
</div>
<img class="project__thumbnail" src="images/project-a.png"
<h3 class="project__title">Yoga Studio Landing Page Website and
Design</h3>
<p><a class="project__author" href="profile.html">By Dennis
Ivanov</a></p>
Feedback (72 Votes)
</p>
</span>
</span>
</span>
</div>
66
</div>
</a>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</main>
</body>
</html>
4.1.2) Python Code:-
views.py
from django.shortcuts import render, redirect

from django.contrib.auth import login, authenticate, logout
from django.contrib import messages
from django.contrib.auth.models import User
from .forms import CustomUserCreationForm, ProfileForm, SkillForm,
MessageForm
from .models import Profile, skill, Message
from django.db.models import Q
from django.contrib.auth.decorators import login_required
from .utils import searchProfile, paginateProfile
# Create your views here.
def loginUser(request):
67
# This if condition will check if the user is loged in and if its true and then if the
user tries to access the login page by search bar it will restrict and redirect it to the
profiles page
if request.user.is_authenticated:
return redirect('profiles')
if request.method == 'POST':
page = 'login'
username = request.POST['username'].lower()
password = request.POST['password']
try:
user = User.objects.get(username=username)
except:
messages.error(request, "User doesn't exist")
user = authenticate(request, username=username, password=password)
if user is not None:
login(request, user)
return redirect(request.GET['next'] if 'next' in request.GET else 'account')
else:
messages.error(request, "User or password is wrong")
return render(request, 'users/login_register.html')
def logoutUser(request):
logout(request)
messages.info(request, "User successfully loged out")
return redirect('login')
def registerUser(request):
68
page = 'register'
form = CustomUserCreationForm()
form = CustomUserCreationForm(request.POST)
if form.is_valid():
user = form.save(commit=False)
user.username = user.username.lower()
user.save()
messages.success(request, "User account was created!")
login(request, user)
return redirect('edit-account')
else:
messages.error(request, "An error has been occurred during reqistration")
context = {'page': page, 'form': form}

return render(request, 'users/login_register.html', context)
def profiles(request):
profiles , search_query = searchProfile(request)
custom_range, profiles = paginateProfile(request, profiles, 6)
context = {'profiles': profiles, "search_query": search_query, 'custom_range':

custom_range}
return render(request, 'users/profiles.html', context)
def singleProfile(request, pk):

profile = Profile.objects.get(id = pk)
topskills = profile.skill_set.exclude(description__exact="")
otherskills = profile.skill_set.filter(description="")
69
context = {"profile": profile, "topskills": topskills, "otherskills": otherskills}
return render(request, 'users/single-profile.html', context)
@login_required(login_url="login")
def userAccount(request):
profile = request.user.profile
skills = profile.skill_set.all()
projects = profile.project_set.all()
context = {"profile": profile, "skills": skills, "projects": projects}

return render(request, 'users/account.html', context)
@login_required(login_url="login")
def editAccount(request):
form = ProfileForm(instance=profile)
form = ProfileForm(request.POST, request.FILES, instance=profile)
if form.is_valid():
form.save()
return redirect("account")
context = {"form": form}

return render(request, "users/profile_form.html", context)
@login_required(login_url='login')
def createSkill(request):
form = SkillForm()
form = SkillForm(request.POST)
if form.is_valid():
skill = form.save(commit=False)
skill.owner = profile
skill.save()
70
messages.success(request, "skill was added successfully!")
context = {'form': form}

return render(request, "users/skill_form.html", context)
def updateSkill(request, pk):
skill = profile.skill_set.get(id=pk)
form = SkillForm(instance=skill)
form = SkillForm(request.POST, instance=skill)
if form.is_valid():
form.save()
messages.success(request, "skill was updated successfully!")
context = {'form': form}

return render(request, "users/skill_form.html", context)
def deleteSkill(request, pk):
skill = profile.skill_set.get(id=pk)
skill.delete()
messages.success(request, "Skill was deleted successfully!")
return redirect('account')
context = {'object': skill}

return render(request, 'delete_form.html', context)
71
def inbox(request):
messageRequest = profile.messages.all()
unreadCount = messageRequest.filter(is_read = False).count()
context = {'messageRequest': messageRequest, 'unreadCount': unreadCount}
return render(request, 'users/inbox.html', context)
def viewMessage(request, pk):
message = profile.messages.get(id=pk)
if message.is_read == False:
message.is_read = True
message.save()
context = {'message': message}
return render(request, 'users/message.html', context)
def createMessage(request, pk):

recipient = Profile.objects.get(id=pk)
form = MessageForm()
try:
sender = request.user.profile
except:
sender = None
form = MessageForm(request.POST)
if form.is_valid():
message = form.save(commit=False)
message.sender = sender
message.recipient = recipient
if sender:
message.name = sender.name
message.email = sender.email
message.save()
72
messages.success(request, "Your message was successfully sent!")
return redirect('single-profile', pk=recipient.id)
context= {'recipient': recipient, 'form': form}

return render(request, 'users/message_form.html', context)
form.py
from django.forms import ModelForm

from django.contrib.auth.forms import UserCreationForm
from django.contrib.auth.models import User
from .models import Profile, skill, Message
class CustomUserCreationForm(UserCreationForm):
class Meta:
model = User
fields = ['first_name', 'email', 'username', 'password1', 'password2']
labels = {
'first_name': 'Name',
73
}
def __init__(self, *args, **kwargs):

super(CustomUserCreationForm, self).__init__(*args, **kwargs)
for name, field in self.fields.items():

field.widget.attrs.update({'class': 'input'})
class ProfileForm(ModelForm):
class Meta:
model = Profile
fields = ['name', 'email', 'username', 'location', 'short_intro', 'bio', 'profile_image',
'social_github', 'social_linkedin', 'social_twitter', 'social_website', ]

super(ProfileForm, self).__init__(*args, **kwargs)

class SkillForm(ModelForm):
class Meta:
model = skill
fields = '__all__'
exclude = ['owner']

super(SkillForm, self).__init__(*args, **kwargs)

class MessageForm(ModelForm):
class Meta:
model = Message
fields = ['name', 'email', 'subject', 'body']
74
super(MessageForm, self).__init__(*args, **kwargs)

admin.py
from django.contrib import admin

from .models import Project, Tags, Review
# Register your models here.
admin.site.register(Project)
admin.site.register(Review)
admin.site.register(Tags)
75
urls.py
from django.contrib import admin

from django.urls import path
from . import views
urlpatterns = [
# path('', views.home, name='home'),
path('', views.projects, name='projects'),
path('single_projects/<str:pk>/', views.single_projects, name='single_projects'),
path('create-project/', views.create_project, name='create-project'),
path('update-project/<str:pk>/', views.update_project, name='update-project'),
path('delete-project/<str:pk>/', views.delete_project, name='delete-project'),
]
typing_extensions.py
import abc
import collections
import collections.abc
import functools
import inspect
import operator
import sys
76
import types as _types
import typing
import warnings
__all__ = [
# Super-special typing primitives.
'Any',
'ClassVar',
'Concatenate',
'Final',
'LiteralString',
'ParamSpec',
'ParamSpecArgs',
'ParamSpecKwargs',
'Self',
'Type',
'TypeVar',
'TypeVarTuple',
'Unpack',
# ABCs (from collections.abc).

'Awaitable',
'AsyncIterator',
'AsyncIterable',
'Coroutine',
'AsyncGenerator',
'AsyncContextManager',
'Buffer',
'ChainMap',
# Concrete collection types.

'ContextManager',
'Counter',
'Deque',
'DefaultDict',
'NamedTuple',
'OrderedDict',
'TypedDict',
77
# Structural checks, a.k.a. protocols.
'SupportsAbs',
'SupportsBytes',
'SupportsComplex',
'SupportsFloat',
'SupportsIndex',
'SupportsInt',
'SupportsRound',
# One-off things.
'Annotated',
'assert_never',
'assert_type',
'clear_overloads',
'dataclass_transform',
'deprecated',
'get_overloads',
'final',
'get_args',
'get_origin',
'get_original_bases',
'get_protocol_members',
'get_type_hints',
'IntVar',
'is_protocol',
'is_typeddict',
'Literal',
'NewType',
'overload',
'override',
'Protocol',
'reveal_type',
'runtime',
'runtime_checkable',
'Text',
'TypeAlias',
'TypeAliasType',
78
'TypeGuard',
'TYPE_CHECKING',
'Never',
'NoReturn',
'Required',
'NotRequired',
# Pure aliases, have always been in typing

'AbstractSet',
'AnyStr',
'BinaryIO',
'Callable',
'Collection',
'Container',
'Dict',
'ForwardRef',
'FrozenSet',
'Generator',
'Generic',
'Hashable',
'IO',
'ItemsView',
'Iterable',
'Iterator',
'KeysView',
'List',
'Mapping',
'MappingView',
'Match',
'MutableMapping',
'MutableSequence',
'MutableSet',
'Optional',
'Pattern',
'Reversible',
'Sequence',
'Set',
'Sized',
79
'TextIO',
'Tuple',
'Union',
'ValuesView',
'cast',
'no_type_check',
'no_type_check_decorator',
]
# for backward compatibility

PEP_560 = True
GenericMeta = type
# The functions below are modified copies of typing internal helpers.

# They are needed by _ProtocolMeta and they provide support for PEP 646.
class _Sentinel:
def __repr__(self):
return "<sentinel>"
_marker = _Sentinel()
def _check_generic(cls, parameters, elen=_marker):

"""Check correct count for parameters of a generic cls (internal helper).
This gives a nice error message in case of count mismatch.
"""
if not elen:
raise TypeError(f"{cls} is not a generic class")
if elen is _marker:
if not hasattr(cls, "__parameters__") or not cls.__parameters__:
raise TypeError(f"{cls} is not a generic class")

elen = len(cls.__parameters__)
alen = len(parameters)
if alen != elen:
if hasattr(cls, "__parameters__"):
80
parameters = [p for p in cls.__parameters__ if not _is_unpack(p)]
num_tv_tuples = sum(isinstance(p, TypeVarTuple) for p in parameters)
if (num_tv_tuples > 0) and (alen >= elen - num_tv_tuples):
return
raise TypeError(f"Too {'many' if alen > elen else 'few'} parameters for {cls};"
f" actual {alen}, expected {elen}")
if sys.version_info >= (3, 10):

def _should_collect_from_parameters(t):
return isinstance(
t, (typing._GenericAlias, _types.GenericAlias, _types.UnionType)
)
elif sys.version_info >= (3, 9):
return isinstance(t, (typing._GenericAlias, _types.GenericAlias))
else:
return isinstance(t, typing._GenericAlias) and not t._special
def _collect_type_vars(types, typevar_types=None):

"""Collect all type variable contained in types in order of
first appearance (lexicographic order). For example::
_collect_type_vars((T, List[S, T])) == (T, S)

"""
if typevar_types is None:
typevar_types = typing.TypeVar
tvars = []
for t in types:
if (
isinstance(t, typevar_types) and
t not in tvars and
not _is_unpack(t)
):
tvars.append(t)
if _should_collect_from_parameters(t):
81
tvars.extend([t for t in t.__parameters__ if t not in tvars])
return tuple(tvars)
NoReturn = typing.NoReturn
# Some unconstrained type variables. These are used by the container types.
# (These are not for export.)
T = typing.TypeVar('T') # Any type.
KT = typing.TypeVar('KT') # Key type.
VT = typing.TypeVar('VT') # Value type.
T_co = typing.TypeVar('T_co', covariant=True) # Any type covariant containers.
T_contra = typing.TypeVar('T_contra', contravariant=True) # Ditto contravariant.

from typing import Any
else:
class _AnyMeta(type):
def __instancecheck__(self, obj):
if self is Any:
raise TypeError("typing_extensions.Any cannot be used with isinstance()")
return super().__instancecheck__(obj)
def __repr__(self):
if self is Any:
return "typing_extensions.Any"
return super().__repr__()
class Any(metaclass=_AnyMeta):
"""Special type indicating an unconstrained type.
- Any is compatible with every type.
- Any assumed to have all methods.
- All values assumed to be instances of Any.
Note that all the above statements are true from the point of view of
static type checkers. At runtime, Any should not be used with instance
checks.
82
"""
def __new__(cls, *args, **kwargs):
if cls is Any:
raise TypeError("Any cannot be instantiated")
return super().__new__(cls, *args, **kwargs)
ClassVar = typing.ClassVar
class _ExtensionsSpecialForm(typing._SpecialForm, _root=True):

def __repr__(self):
return 'typing_extensions.' + self._name
# On older versions of typing there is an internal class named "Final".

# 3.8+
if hasattr(typing, 'Final') and sys.version_info[:2] >= (3, 7):
Final = typing.Final
# 3.7
else:
class _FinalForm(_ExtensionsSpecialForm, _root=True):
def __getitem__(self, parameters):
item = typing._type_check(parameters,
f'{self._name} accepts only a single type.')
return typing._GenericAlias(self, (item,))
Final = _FinalForm('Final',
doc="""A special typing construct to indicate that a name
cannot be re-assigned or overridden in a subclass.
For example:
MAX_SIZE: Final = 9000

MAX_SIZE += 1 # Error reported by type checker
class Connection:
TIMEOUT: Final[int] = 10
class FastConnector(Connection):
TIMEOUT = 1 # Error reported by type checker
83
There is no runtime checking of these properties.""")

final = typing.final
else:
# @final exists in 3.8+, but we backport it for all versions
# before 3.11 to keep support for the __final__ attribute.
# See https://bugs.python.org/issue46342
def final(f):
"""This decorator can be used to indicate to type checkers that
the decorated method cannot be overridden, and decorated class
cannot be subclassed. For example:
class Base:
@final
def done(self) -> None:
...
class Sub(Base):
def done(self) -> None: # Error reported by type checker
...
@final
class Leaf:
...
class Other(Leaf): # Error reported by type checker
...
There is no runtime checking of these properties. The decorator

sets the ``__final__`` attribute to ``True`` on the decorated object
to allow runtime introspection.
"""
try:
f.__final__ = True
except (AttributeError, TypeError):
# Skip the attribute silently if it is not writable.
# AttributeError happens if the object has __slots__ or a
# read-only property, TypeError if it's a builtin class.
pass
84
return f
def IntVar(name):
return typing.TypeVar(name)
# A Literal bug was fixed in 3.11.0, 3.10.1 and 3.9.8

if sys.version_info >= (3, 10, 1):
Literal = typing.Literal
else:
def _flatten_literal_params(parameters):
"""An internal helper for Literal creation: flatten Literals among parameters"""
params = []
for p in parameters:
if isinstance(p, _LiteralGenericAlias):
params.extend(p.__args__)
else:
params.append(p)
return tuple(params)
def _value_and_type_iter(params):
for p in params:
yield p, type(p)
class _LiteralGenericAlias(typing._GenericAlias, _root=True):

def __eq__(self, other):
if not isinstance(other, _LiteralGenericAlias):
return NotImplemented
these_args_deduped = set(_value_and_type_iter(self.__args__))
other_args_deduped = set(_value_and_type_iter(other.__args__))
return these_args_deduped == other_args_deduped
def __hash__(self):
return hash(frozenset(_value_and_type_iter(self.__args__)))
class _LiteralForm(_ExtensionsSpecialForm, _root=True):

def __init__(self, doc: str):
self._name = 'Literal'
85
self._doc = self.__doc__ = doc

if not isinstance(parameters, tuple):
parameters = (parameters,)
parameters = _flatten_literal_params(parameters)
val_type_pairs = list(_value_and_type_iter(parameters))
try:
deduped_pairs = set(val_type_pairs)
except TypeError:
# unhashable parameters
pass
else:
# similar logic to typing._deduplicate on Python 3.9+
if len(deduped_pairs) < len(val_type_pairs):
new_parameters = []
for pair in val_type_pairs:
if pair in deduped_pairs:
new_parameters.append(pair[0])
deduped_pairs.remove(pair)
assert not deduped_pairs, deduped_pairs
parameters = tuple(new_parameters)
return _LiteralGenericAlias(self, parameters)
Literal = _LiteralForm(doc="""\
A type that can be used to indicate to type checkers
that the corresponding value has a value literally equivalent
to the provided parameter. For example:
var: Literal[4] = 4
The type checker understands that 'var' is literally equal to

the value 4 and no other value.
Literal[...] cannot be subclassed. There is no runtime

checking verifying that the parameter is actually a value
instead of a type.""")
86
_overload_dummy = typing._overload_dummy
if hasattr(typing, "get_overloads"): # 3.11+

overload = typing.overload
get_overloads = typing.get_overloads
clear_overloads = typing.clear_overloads
else:
# {module: {qualname: {firstlineno: func}}}
_overload_registry = collections.defaultdict(
functools.partial(collections.defaultdict, dict)
)
def overload(func):
"""Decorator for overloaded functions/methods.
In a stub file, place two or more stub definitions for the same
function in a row, each decorated with @overload. For example:
@overload
def utf8(value: None) -> None: ...
@overload
def utf8(value: bytes) -> bytes: ...
@overload
def utf8(value: str) -> bytes: ...
In a non-stub file (i.e. a regular .py file), do the same but

follow it with an implementation. The implementation should *not*
be decorated with @overload. For example:
@overload
def utf8(value: None) -> None: ...
@overload
def utf8(value: bytes) -> bytes: ...
@overload
def utf8(value: str) -> bytes: ...
def utf8(value):
# implementation goes here
87
The overloads for a function can be retrieved at runtime using the
get_overloads() function.
"""
# classmethod and staticmethod
f = getattr(func, "__func__", func)
try:
_overload_registry[f.__module__][f.__qualname__][
f.__code__.co_firstlineno
] = func
except AttributeError:
# Not a normal function; ignore.
pass
return _overload_dummy
def get_overloads(func):
"""Return all defined overloads for *func* as a sequence."""
# classmethod and staticmethod
f = getattr(func, "__func__", func)
if f.__module__ not in _overload_registry:
return []
mod_dict = _overload_registry[f.__module__]
if f.__qualname__ not in mod_dict:
return []
return list(mod_dict[f.__qualname__].values())
def clear_overloads():
"""Clear all overloads in the registry."""
_overload_registry.clear()
# This is not a real generic class. Don't use outside annotations.

Type = typing.Type
# Various ABCs mimicking those in collections.abc.

# A few are simply re-exported for completeness.
Awaitable = typing.Awaitable
Coroutine = typing.Coroutine
88
AsyncIterable = typing.AsyncIterable
AsyncIterator = typing.AsyncIterator
Deque = typing.Deque
ContextManager = typing.ContextManager
AsyncContextManager = typing.AsyncContextManager
DefaultDict = typing.DefaultDict
# 3.7.2+
if hasattr(typing, 'OrderedDict'):
OrderedDict = typing.OrderedDict
# 3.7.0-3.7.2
else:
OrderedDict = typing._alias(collections.OrderedDict, (KT, VT))
Counter = typing.Counter
ChainMap = typing.ChainMap
AsyncGenerator = typing.AsyncGenerator
Text = typing.Text
TYPE_CHECKING = typing.TYPE_CHECKING
_PROTO_ALLOWLIST = {
'collections.abc': [
'Callable', 'Awaitable', 'Iterable', 'Iterator', 'AsyncIterable',
'Hashable', 'Sized', 'Container', 'Collection', 'Reversible', 'Buffer',
],
'contextlib': ['AbstractContextManager', 'AbstractAsyncContextManager'],
'typing_extensions': ['Buffer'],
}
_EXCLUDED_ATTRS = {
"__abstractmethods__", "__annotations__", "__weakref__", "_is_protocol",
"_is_runtime_protocol", "__dict__", "__slots__", "__parameters__",
"__orig_bases__", "__module__", "_MutableMapping__marker", "__doc__",
"__subclasshook__", "__orig_class__", "__init__", "__new__",
"__protocol_attrs__", "__callable_proto_members_only__",
}
89
if sys.version_info < (3, 8):
_EXCLUDED_ATTRS |= {
"_gorg", "__next_in_mro__", "__extra__", "__tree_hash__", "__args__",
"__origin__"
}

_EXCLUDED_ATTRS.add("__class_getitem__")

_EXCLUDED_ATTRS.add("__type_params__")
_EXCLUDED_ATTRS = frozenset(_EXCLUDED_ATTRS)
def _get_protocol_attrs(cls):
attrs = set()
for base in cls.__mro__[:-1]: # without object
if base.__name__ in {'Protocol', 'Generic'}:
continue
annotations = getattr(base, '__annotations__', {})
for attr in (*base.__dict__, *annotations):
if (not attr.startswith('_abc_') and attr not in _EXCLUDED_ATTRS):
attrs.add(attr)
return attrs
def _maybe_adjust_parameters(cls):
"""Helper function used in Protocol.__init_subclass__ and
_TypedDictMeta.__new__.
The contents of this function are very similar

to logic found in typing.Generic.__init_subclass__
on the CPython main branch.
"""
tvars = []
if '__orig_bases__' in cls.__dict__:
tvars = _collect_type_vars(cls.__orig_bases__)
90
# Look for Generic[T1, ..., Tn] or Protocol[T1, ..., Tn].
# If found, tvars must be a subset of it.
# If not found, tvars is it.

# Also check for and reject plain Generic,
# and reject multiple Generic[...] and/or Protocol[...].
gvars = None
for base in cls.__orig_bases__:
if (isinstance(base, typing._GenericAlias) and
base.__origin__ in (typing.Generic, Protocol)):
# for error messages
the_base = base.__origin__.__name__
if gvars is not None:
raise TypeError(
"Cannot inherit from Generic[...]"
" and/or Protocol[...] multiple types.")
gvars = base.__parameters__
if gvars is None:
gvars = tvars
else:
tvarset = set(tvars)
gvarset = set(gvars)
if not tvarset <= gvarset:
s_vars = ', '.join(str(t) for t in tvars if t not in gvarset)
s_args = ', '.join(str(g) for g in gvars)
raise TypeError(f"Some type variables ({s_vars}) are"
f" not listed in {the_base}[{s_args}]")
tvars = gvars
cls.__parameters__ = tuple(tvars)
def _caller(depth=2):
try:
return sys._getframe(depth).f_globals.get('__name__', '__main__')
except (AttributeError, ValueError): # For platforms without _getframe()
return None
# The performance of runtime-checkable protocols is significantly improved on

91
Python 3.12,
# so we backport the 3.12 version of Protocol to Python <=3.11
Protocol = typing.Protocol
else:
def _allow_reckless_class_checks(depth=3):
"""Allow instance and class checks for special stdlib modules.
The abc and functools modules indiscriminately call isinstance() and
issubclass() on the whole MRO of a user class, which may contain protocols.
"""
return _caller(depth) in {'abc', 'functools', None}
def _no_init(self, *args, **kwargs):

if type(self)._is_protocol:
raise TypeError('Protocols cannot be instantiated')

# Inheriting from typing._ProtocolMeta isn't actually desirable,
# but is necessary to allow typing.Protocol and typing_extensions.Protocol
# to mix without getting TypeErrors about "metaclass conflict"
_typing_Protocol = typing.Protocol
_ProtocolMetaBase = type(_typing_Protocol)
else:
_typing_Protocol = _marker
_ProtocolMetaBase = abc.ABCMeta
class _ProtocolMeta(_ProtocolMetaBase):
# This metaclass is somewhat unfortunate,
# but is necessary for several reasons...
#
# NOTE: DO NOT call super() in any methods in this class
# That would call the methods on typing._ProtocolMeta on Python 3.8-3.11
# and those are slow
def __new__(mcls, name, bases, namespace, **kwargs):
if name == "Protocol" and len(bases) < 2:
pass
elif {Protocol, _typing_Protocol} & set(bases):
for base in bases:
if not (
92
base in {object, typing.Generic, Protocol, _typing_Protocol}
or base.__name__ in _PROTO_ALLOWLIST.get(base.__module__,
[])
or is_protocol(base)
):
raise TypeError(
f"Protocols can only inherit from other protocols, "
f"got {base!r}"
)
return abc.ABCMeta.__new__(mcls, name, bases, namespace, **kwargs)
def __init__(cls, *args, **kwargs):

abc.ABCMeta.__init__(cls, *args, **kwargs)
if getattr(cls, "_is_protocol", False):
cls.__protocol_attrs__ = _get_protocol_attrs(cls)
# PEP 544 prohibits using issubclass()
# with protocols that have non-method members.
cls.__callable_proto_members_only__ = all(
callable(getattr(cls, attr, None)) for attr in cls.__protocol_attrs__
)
def __subclasscheck__(cls, other):

if cls is Protocol:
return type.__subclasscheck__(cls, other)
if (
getattr(cls, '_is_protocol', False)
and not _allow_reckless_class_checks()
):
if not isinstance(other, type):
# Same error message as for issubclass(1, int).
raise TypeError('issubclass() arg 1 must be a class')
if (
not cls.__callable_proto_members_only__
and cls.__dict__.get("__subclasshook__") is _proto_hook
):
raise TypeError(
"Protocols with non-method members don't support issubclass()"
)
93
if not getattr(cls, '_is_runtime_protocol', False):
raise TypeError(
"Instance and class checks can only be used with "
"@runtime_checkable protocols"
)
return abc.ABCMeta.__subclasscheck__(cls, other)
def __instancecheck__(cls, instance):

# We need this method for situations where attributes are
# assigned in __init__.
if cls is Protocol:
return type.__instancecheck__(cls, instance)
if not getattr(cls, "_is_protocol", False):
# i.e., it's a concrete subclass of a protocol
return abc.ABCMeta.__instancecheck__(cls, instance)
if (
not getattr(cls, '_is_runtime_protocol', False) and
not _allow_reckless_class_checks()
):
raise TypeError("Instance and class checks can only be used with"
" @runtime_checkable protocols")
if abc.ABCMeta.__instancecheck__(cls, instance):
return True
for attr in cls.__protocol_attrs__:

try:
val = inspect.getattr_static(instance, attr)
break
if val is None and callable(getattr(cls, attr, None)):
break
else:
return True
return False
94
def __eq__(cls, other):
# Hack so that typing.Generic.__class_getitem__
# treats typing_extensions.Protocol
# as equivalent to typing.Protocol on Python 3.8+
if abc.ABCMeta.__eq__(cls, other) is True:
return True
return (
cls is Protocol and other is getattr(typing, "Protocol", object())
)
# This has to be defined, or the abc-module cache

# complains about classes with this metaclass being unhashable,
# if we define only __eq__!
def __hash__(cls) -> int:
return type.__hash__(cls)
@classmethod
def _proto_hook(cls, other):
if not cls.__dict__.get('_is_protocol', False):
for attr in cls.__protocol_attrs__:

for base in other.__mro__:
# Check if the members appears in the class dictionary...
if attr in base.__dict__:
if base.__dict__[attr] is None:
break
# ...or in annotations, if it is a sub-protocol.

annotations = getattr(base, '__annotations__', {})
if (
isinstance(annotations, collections.abc.Mapping)
and attr in annotations
and is_protocol(other)
):
break
else:
95
return True

class Protocol(typing.Generic, metaclass=_ProtocolMeta):
__doc__ = typing.Protocol.__doc__
__slots__ = ()
_is_protocol = True
_is_runtime_protocol = False
def __init_subclass__(cls, *args, **kwargs):

super().__init_subclass__(*args, **kwargs)
# Determine if this is a protocol or a concrete subclass.

if not cls.__dict__.get('_is_protocol', False):
cls._is_protocol = any(b is Protocol for b in cls.__bases__)
# Set (or override) the protocol subclass hook.

if '__subclasshook__' not in cls.__dict__:
cls.__subclasshook__ = _proto_hook
# Prohibit instantiation for protocol classes

if cls._is_protocol and cls.__init__ is Protocol.__init__:
cls.__init__ = _no_init
else:
class Protocol(metaclass=_ProtocolMeta):
# There is quite a lot of overlapping code with typing.Generic.
# Unfortunately it is hard to avoid this on Python <3.8,
# as the typing module on Python 3.7 doesn't let us subclass typing.Generic!
"""Base class for protocol classes. Protocol classes are defined as::
class Proto(Protocol):
def meth(self) -> int:
...
Such classes are primarily used with static type checkers that recognize
structural subtyping (static duck-typing), for example::
96
class C:
def meth(self) -> int:
return 0
def func(x: Proto) -> int:

return x.meth()
func(C()) # Passes static type check
See PEP 544 for details. Protocol classes decorated with

@typing_extensions.runtime_checkable act
as simple-minded runtime-checkable protocols that check
only the presence of given attributes, ignoring their type signatures.
Protocol classes can be generic, they are defined as::
class GenProto(Protocol[T]):
def meth(self) -> T:
...
"""
__slots__ = ()
_is_protocol = True
_is_runtime_protocol = False
def __new__(cls, *args, **kwds):

if cls is Protocol:
raise TypeError("Type Protocol cannot be instantiated; "
"it can only be used as a base class")
return super().__new__(cls)
@typing._tp_cache
def __class_getitem__(cls, params):
if not isinstance(params, tuple):
params = (params,)
if not params and cls is not typing.Tuple:
raise TypeError(
f"Parameter list to {cls.__qualname__}[...] cannot be empty")
97
msg = "Parameters to generic types must be types."
params = tuple(typing._type_check(p, msg) for p in params)
if cls is Protocol:
# Generic can only be subscripted with unique type variables.
if not all(isinstance(p, typing.TypeVar) for p in params):
i=0
while isinstance(params[i], typing.TypeVar):
i += 1
raise TypeError(
"Parameters to Protocol[...] must all be type variables."
f" Parameter {i + 1} is {params[i]}")

if len(set(params)) != len(params):
raise TypeError(
"Parameters to Protocol[...] must all be unique")
else:
# Subscripting a regular Generic subclass.
_check_generic(cls, params, len(cls.__parameters__))
return typing._GenericAlias(cls, params)

if '__orig_bases__' in cls.__dict__:
error = typing.Generic in cls.__orig_bases__
else:
error = typing.Generic in cls.__bases__
if error:
raise TypeError("Cannot inherit from plain Generic")
_maybe_adjust_parameters(cls)
# Determine if this is a protocol or a concrete subclass.

if not cls.__dict__.get('_is_protocol', None):
cls._is_protocol = any(b is Protocol for b in cls.__bases__)
# Set (or override) the protocol subclass hook.

if '__subclasshook__' not in cls.__dict__:
cls.__subclasshook__ = _proto_hook
# Prohibit instantiation for protocol classes

if cls._is_protocol and cls.__init__ is Protocol.__init__:
cls.__init__ = _no_init
98
runtime_checkable = typing.runtime_checkable
else:
def runtime_checkable(cls):
"""Mark a protocol class as a runtime protocol, so that it
can be used with isinstance() and issubclass(). Raise TypeError
if applied to a non-protocol class.
This allows a simple-minded structural check very similar to the

one-offs in collections.abc such as Hashable.
"""
if not (
(isinstance(cls, _ProtocolMeta) or issubclass(cls, typing.Generic))
and getattr(cls, "_is_protocol", False)
):
raise TypeError('@runtime_checkable can be only applied to protocol
classes,'
f' got {cls!r}')
cls._is_runtime_protocol = True
return cls
# Exists for backwards compatibility.

runtime = runtime_checkable
# Our version of runtime-checkable protocols is faster on Python 3.7-3.11

SupportsInt = typing.SupportsInt
SupportsFloat = typing.SupportsFloat
SupportsComplex = typing.SupportsComplex
SupportsBytes = typing.SupportsBytes
SupportsIndex = typing.SupportsIndex
SupportsAbs = typing.SupportsAbs
SupportsRound = typing.SupportsRound
else:
99
@runtime_checkable
class SupportsInt(Protocol):
"""An ABC with one abstract method __int__."""
__slots__ = ()
@abc.abstractmethod
def __int__(self) -> int:
pass
@runtime_checkable
class SupportsFloat(Protocol):
"""An ABC with one abstract method __float__."""
__slots__ = ()
@abc.abstractmethod
def __float__(self) -> float:
pass
@runtime_checkable
class SupportsComplex(Protocol):
"""An ABC with one abstract method __complex__."""
__slots__ = ()
@abc.abstractmethod
def __complex__(self) -> complex:
pass
@runtime_checkable
class SupportsBytes(Protocol):
"""An ABC with one abstract method __bytes__."""
__slots__ = ()
@abc.abstractmethod
def __bytes__(self) -> bytes:
pass
@runtime_checkable
class SupportsIndex(Protocol):
__slots__ = ()
100
@abc.abstractmethod
def __index__(self) -> int:
pass
@runtime_checkable
class SupportsAbs(Protocol[T_co]):
"""
An ABC with one abstract method __abs__ that is covariant in its return type.
"""
__slots__ = ()
@abc.abstractmethod
def __abs__(self) -> T_co:
pass
@runtime_checkable
class SupportsRound(Protocol[T_co]):
"""
An ABC with one abstract method __round__ that is covariant in its return type.
"""
__slots__ = ()
@abc.abstractmethod
def __round__(self, ndigits: int = 0) -> T_co:
pass
def _ensure_subclassable(mro_entries):
def inner(func):
if sys.implementation.name == "pypy" and sys.version_info < (3, 9):
cls_dict = {
"__call__": staticmethod(func),
"__mro_entries__": staticmethod(mro_entries)
}
t = type(func.__name__, (), cls_dict)
return functools.update_wrapper(t(), func)
else:
101
func.__mro_entries__ = mro_entries
return func
return inner

# The standard library TypedDict in Python 3.8 does not store runtime information
# about which (if any) keys are optional. See https://bugs.python.org/issue38834
# The standard library TypedDict in Python 3.9.0/1 does not honour the "total"
# keyword with old-style TypedDict(). See https://bugs.python.org/issue42059
# The standard library TypedDict below Python 3.11 does not store runtime
# information about optional and required keys when using Required or
NotRequired.
# Generic TypedDicts are also impossible using typing.TypedDict on Python
<3.11.
# Aaaand on 3.12 we add __orig_bases__ to TypedDict
# to enable better runtime introspection.
# On 3.13 we deprecate some odd ways of creating TypedDicts.
TypedDict = typing.TypedDict
_TypedDictMeta = typing._TypedDictMeta
is_typeddict = typing.is_typeddict
else:
# 3.10.0 and later
_TAKES_MODULE = "module" in
inspect.signature(typing._type_check).parameters

_fake_name = "Protocol"
else:
_fake_name = "_Protocol"
class _TypedDictMeta(type):
def __new__(cls, name, bases, ns, total=True):
"""Create new typed dict class object.
This method is called when TypedDict is subclassed,

or when TypedDict is instantiated. This way
TypedDict supports all three syntax forms described in its docstring.
102
Subclasses and instances of TypedDict return actual dictionaries.
"""
for base in bases:
if type(base) is not _TypedDictMeta and base is not typing.Generic:
raise TypeError('cannot inherit from both a TypedDict type '
'and a non-TypedDict base class')
if any(issubclass(b, typing.Generic) for b in bases):

generic_base = (typing.Generic,)
else:
generic_base = ()
# typing.py generally doesn't let you inherit from plain Generic, unless
# the name of the class happens to be "Protocol" (or "_Protocol" on 3.7).
tp_dict = type.__new__(_TypedDictMeta, _fake_name, (*generic_base, dict),
ns)
tp_dict.__name__ = name
if tp_dict.__qualname__ == _fake_name:
tp_dict.__qualname__ = name
if not hasattr(tp_dict, '__orig_bases__'):

tp_dict.__orig_bases__ = bases
annotations = {}
own_annotations = ns.get('__annotations__', {})
msg = "TypedDict('Name', {f0: t0, f1: t1, ...}); each t must be a type"
if _TAKES_MODULE:
own_annotations = {
n: typing._type_check(tp, msg, module=tp_dict.__module__)
for n, tp in own_annotations.items()
}
else:
own_annotations = {
n: typing._type_check(tp, msg)
for n, tp in own_annotations.items()
}
required_keys = set()
103
optional_keys = set()
for base in bases:

annotations.update(base.__dict__.get('__annotations__', {}))
required_keys.update(base.__dict__.get('__required_keys__', ()))
optional_keys.update(base.__dict__.get('__optional_keys__', ()))
annotations.update(own_annotations)
for annotation_key, annotation_type in own_annotations.items():
annotation_origin = get_origin(annotation_type)
if annotation_origin is Annotated:
annotation_args = get_args(annotation_type)
if annotation_args:
annotation_type = annotation_args[0]
annotation_origin = get_origin(annotation_type)
if annotation_origin is Required:
required_keys.add(annotation_key)
elif annotation_origin is NotRequired:
optional_keys.add(annotation_key)
elif total:
required_keys.add(annotation_key)
else:
optional_keys.add(annotation_key)
tp_dict.__annotations__ = annotations
tp_dict.__required_keys__ = frozenset(required_keys)
tp_dict.__optional_keys__ = frozenset(optional_keys)
if not hasattr(tp_dict, '__total__'):
tp_dict.__total__ = total
return tp_dict
__call__ = dict # static method
def __subclasscheck__(cls, other):

# Typed dicts are only for static structural subtyping.
raise TypeError('TypedDict does not support instance and class checks')
__instancecheck__ = __subclasscheck__
104
_TypedDict = type.__new__(_TypedDictMeta, 'TypedDict', (), {})
@_ensure_subclassable(lambda bases: (_TypedDict,))

def TypedDict(__typename, __fields=_marker, *, total=True, **kwargs):
"""A simple typed namespace. At runtime it is equivalent to a plain dict.
TypedDict creates a dictionary type such that a type checker will expect all
instances to have a certain set of keys, where each key is
associated with a value of a consistent type. This expectation
is not checked at runtime.
Usage::
class Point2D(TypedDict):
x: int
y: int
label: str
a: Point2D = {'x': 1, 'y': 2, 'label': 'good'} # OK

b: Point2D = {'z': 3, 'label': 'bad'} # Fails type check
assert Point2D(x=1, y=2, label='first') == dict(x=1, y=2, label='first')
The type info can be accessed via the Point2D.__annotations__ dict, and
the Point2D.__required_keys__ and Point2D.__optional_keys__ frozensets.
TypedDict supports an additional equivalent form::
Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': str})
By default, all keys must be present in a TypedDict. It is possible

to override this by specifying totality::
class Point2D(TypedDict, total=False):

x: int
y: int
This means that a Point2D TypedDict can have any of the keys omitted. A type
checker is only expected to support a literal False or True as the value of
the total argument. True is the default, and makes all items defined in the
class body be required.
105
The Required and NotRequired special forms can also be used to mark
individual keys as being required or not required::
class Point2D(TypedDict):
x: int # the "x" key must always be present (Required is the default)
y: NotRequired[int] # the "y" key can be omitted
See PEP 655 for more details on Required and NotRequired.

"""
if __fields is _marker or __fields is None:
if __fields is _marker:
deprecated_thing = "Failing to pass a value for the 'fields' parameter"
else:
deprecated_thing = "Passing `None` as the 'fields' parameter"
example = f"`{__typename} = TypedDict({__typename!r}, {{}})`"

deprecation_msg = (
f"{deprecated_thing} is deprecated and will be disallowed in "

"Python 3.15. To create a TypedDict class with 0 fields "
"using the functional syntax, pass an empty dictionary, e.g. "
) + example + "."
warnings.warn(deprecation_msg, DeprecationWarning, stacklevel=2)
__fields = kwargs
elif kwargs:
raise TypeError("TypedDict takes either a dict or keyword arguments,"
" but not both")
if kwargs:
warnings.warn(
"The kwargs-based syntax for TypedDict definitions is deprecated "
"in Python 3.11, will be removed in Python 3.13, and may not be "
"understood by third-party type checkers.",
DeprecationWarning,
stacklevel=2,
)
ns = {'__annotations__': dict(__fields)}
module = _caller()
if module is not None:
# Setting correct module is necessary to make typed dict classes pickleable.
106
ns['__module__'] = module
td = _TypedDictMeta(__typename, (), ns, total=total)

td.__orig_bases__ = (TypedDict,)
return td
if hasattr(typing, "_TypedDictMeta"):
_TYPEDDICT_TYPES = (typing._TypedDictMeta, _TypedDictMeta)
else:
_TYPEDDICT_TYPES = (_TypedDictMeta,)
def is_typeddict(tp):
"""Check if an annotation is a TypedDict class
For example::
class Film(TypedDict):
title: str
year: int
is_typeddict(Film) # => True

is_typeddict(Union[list, str]) # => False
"""
# On 3.8, this would otherwise return True
if hasattr(typing, "TypedDict") and tp is typing.TypedDict:
return False
return isinstance(tp, _TYPEDDICT_TYPES)
if hasattr(typing, "assert_type"):
assert_type = typing.assert_type
else:
def assert_type(__val, __typ):
"""Assert (to the type checker) that the value is of the given type.
When the type checker encounters a call to assert_type(), it

emits an error if the value is not of the specified type::
def greet(name: str) -> None:

assert_type(name, str) # ok
107
assert_type(name, int) # type checker error
At runtime this returns the first argument unchanged and otherwise

does nothing.
"""
return __val
if hasattr(typing, "Required"):
get_type_hints = typing.get_type_hints
else:
# replaces _strip_annotations()
def _strip_extras(t):
"""Strips Annotated, Required and NotRequired from a given type."""
if isinstance(t, _AnnotatedAlias):
return _strip_extras(t.__origin__)
if hasattr(t, "__origin__") and t.__origin__ in (Required, NotRequired):
return _strip_extras(t.__args__[0])
if isinstance(t, typing._GenericAlias):
stripped_args = tuple(_strip_extras(a) for a in t.__args__)
if stripped_args == t.__args__:
return t
return t.copy_with(stripped_args)
if hasattr(_types, "GenericAlias") and isinstance(t, _types.GenericAlias):
return t
return _types.GenericAlias(t.__origin__, stripped_args)
if hasattr(_types, "UnionType") and isinstance(t, _types.UnionType):
return t
return functools.reduce(operator.or_, stripped_args)
return t
def get_type_hints(obj, globalns=None, localns=None, include_extras=False):

"""Return type hints for an object.
This is often the same as obj.__annotations__, but it handles

forward references encoded as string literals, adds Optional[t] if a
108
default value equal to None is set and recursively replaces all
'Annotated[T, ...]', 'Required[T]' or 'NotRequired[T]' with 'T'
(unless 'include_extras=True').
The argument may be a module, class, method, or function. The annotations

are returned as a dictionary. For classes, annotations include also
inherited members.
TypeError is raised if the argument is not of a type that can contain

annotations, and an empty dictionary is returned if no annotations are
present.
BEWARE -- the behavior of globalns and localns is counterintuitive

(unless you are familiar with how eval() and exec() work). The
search order is locals first, then globals.
- If no dict arguments are passed, an attempt is made to use the

globals from obj (or the respective module's globals for classes),
and these are also used as the locals. If the object does not appear
to have globals, an empty dictionary is used.
- If one dict argument is passed, it is used for both globals and

locals.
- If two dict arguments are passed, they specify globals and

locals, respectively.
"""
if hasattr(typing, "Annotated"):
hint = typing.get_type_hints(
obj, globalns=globalns, localns=localns, include_extras=True
)
else:
hint = typing.get_type_hints(obj, globalns=globalns, localns=localns)
if include_extras:
return hint
return {k: _strip_extras(t) for k, t in hint.items()}
# Python 3.9+ has PEP 593 (Annotated)

if hasattr(typing, 'Annotated'):
109
Annotated = typing.Annotated
# Not exported and not a public API, but needed for get_origin() and get_args()
# to work.
_AnnotatedAlias = typing._AnnotatedAlias
# 3.7-3.8
else:
class _AnnotatedAlias(typing._GenericAlias, _root=True):
"""Runtime representation of an annotated type.
At its core 'Annotated[t, dec1, dec2, ...]' is an alias for the type 't'
with extra annotations. The alias behaves like a normal typing alias,
instantiating is the same as instantiating the underlying type, binding
it to types is also the same.
"""
def __init__(self, origin, metadata):
if isinstance(origin, _AnnotatedAlias):
metadata = origin.__metadata__ + metadata
origin = origin.__origin__
super().__init__(origin, origin)
self.__metadata__ = metadata
def copy_with(self, params):

assert len(params) == 1
new_type = params[0]
return _AnnotatedAlias(new_type, self.__metadata__)
def __repr__(self):
return (f"typing_extensions.Annotated[{typing._type_repr(self.__origin__)},
"
f"{', '.join(repr(a) for a in self.__metadata__)}]")
def __reduce__(self):
return operator.getitem, (
Annotated, (self.__origin__,) + self.__metadata__
)

if not isinstance(other, _AnnotatedAlias):
110
if self.__origin__ != other.__origin__:
return False
return self.__metadata__ == other.__metadata__
def __hash__(self):
return hash((self.__origin__, self.__metadata__))
class Annotated:
"""Add context specific metadata to a type.
Example: Annotated[int, runtime_check.Unsigned] indicates to the

hypothetical runtime_check module that this type is an unsigned int.
Every other consumer of this type can ignore this metadata and treat
this type as int.
The first argument to Annotated must be a valid type (and will be in

the __origin__ field), the remaining arguments are kept as a tuple in
the __extra__ field.
Details:
- It's an error to call Ànnotated` with less than two arguments.

- Nested Annotated are flattened::
Annotated[Annotated[T, Ann1, Ann2], Ann3] == Annotated[T, Ann1, Ann2,

Ann3]
- Instantiating an annotated type is equivalent to instantiating the

underlying type::
Annotated[C, Ann1](5) == C(5)
- Annotated can be used as a generic type alias::
Optimized = Annotated[T, runtime.Optimize()]

Optimized[int] == Annotated[int, runtime.Optimize()]
OptimizedList = Annotated[List[T], runtime.Optimize()]

111
OptimizedList[int] == Annotated[List[int], runtime.Optimize()]
"""
__slots__ = ()

raise TypeError("Type Annotated cannot be instantiated.")
@typing._tp_cache
def __class_getitem__(cls, params):
if not isinstance(params, tuple) or len(params) < 2:
raise TypeError("Annotated[...] should be used "
"with at least two arguments (a type and an "
"annotation).")
allowed_special_forms = (ClassVar, Final)
if get_origin(params[0]) in allowed_special_forms:
origin = params[0]
else:
msg = "Annotated[t, ...]: t must be a type."
origin = typing._type_check(params[0], msg)
metadata = tuple(params[1:])
return _AnnotatedAlias(origin, metadata)

raise TypeError(
f"Cannot subclass {cls.__module__}.Annotated"
)
# Python 3.8 has get_origin() and get_args() but those implementations aren't
# Annotated-aware, so we can't use those. Python 3.9's versions don't support
# ParamSpecArgs and ParamSpecKwargs, so only Python 3.10's versions will do.
if sys.version_info[:2] >= (3, 10):
get_origin = typing.get_origin
get_args = typing.get_args
# 3.7-3.9
else:
try:
# 3.9+
from typing import _BaseGenericAlias
112
except ImportError:
_BaseGenericAlias = typing._GenericAlias
try:
# 3.9+
from typing import GenericAlias as _typing_GenericAlias
except ImportError:
_typing_GenericAlias = typing._GenericAlias
def get_origin(tp):
"""Get the unsubscripted version of a type.
This supports generic types, Callable, Tuple, Union, Literal, Final, ClassVar
and Annotated. Return None for unsupported types. Examples::
get_origin(Literal[42]) is Literal
get_origin(int) is None
get_origin(ClassVar[int]) is ClassVar
get_origin(Generic) is Generic
get_origin(Generic[T]) is Generic
get_origin(Union[T, int]) is Union
get_origin(List[Tuple[T, T]][int]) == list
get_origin(P.args) is P
"""
if isinstance(tp, _AnnotatedAlias):
return Annotated
if isinstance(tp, (typing._GenericAlias, _typing_GenericAlias,
_BaseGenericAlias,
ParamSpecArgs, ParamSpecKwargs)):
return tp.__origin__
if tp is typing.Generic:
return typing.Generic
return None
def get_args(tp):
"""Get type arguments with all substitutions performed.
For unions, basic simplifications used by Union constructor are performed.

Examples::
113
get_args(Dict[str, int]) == (str, int)
get_args(int) == ()
get_args(Union[int, Union[T, int], str][int]) == (int, str)
get_args(Union[int, Tuple[T, int]][str]) == (int, Tuple[str, int])
get_args(Callable[[], T][int]) == ([], int)
"""
if isinstance(tp, _AnnotatedAlias):
return (tp.__origin__,) + tp.__metadata__
if isinstance(tp, (typing._GenericAlias, _typing_GenericAlias)):
if getattr(tp, "_special", False):
return ()
res = tp.__args__
if get_origin(tp) is collections.abc.Callable and res[0] is not Ellipsis:
res = (list(res[:-1]), res[-1])
return res
return ()
# 3.10+
if hasattr(typing, 'TypeAlias'):
TypeAlias = typing.TypeAlias
# 3.9
elif sys.version_info[:2] >= (3, 9):
@_ExtensionsSpecialForm
def TypeAlias(self, parameters):
"""Special marker indicating that an assignment should

be recognized as a proper type alias definition by type
checkers.
For example::
Predicate: TypeAlias = Callable[..., bool]
It's invalid when used anywhere except as in the example above.

"""
raise TypeError(f"{self} is not subscriptable")
# 3.7-3.8
else:
TypeAlias = _ExtensionsSpecialForm(
114
'TypeAlias',
doc="""Special marker indicating that an assignment should
be recognized as a proper type alias definition by type
checkers.
For example::
Predicate: TypeAlias = Callable[..., bool]
It's invalid when used anywhere except as in the example

above."""
)
def _set_default(type_param, default):

if isinstance(default, (tuple, list)):
type_param.__default__ = tuple((typing._type_check(d, "Default must be a
type")
for d in default))
elif default != _marker:
type_param.__default__ = typing._type_check(default, "Default must be a
type")
else:
type_param.__default__ = None
def _set_module(typevarlike):
# for pickling:
def_mod = _caller(depth=3)
if def_mod != 'typing_extensions':
typevarlike.__module__ = def_mod
class _DefaultMixin:
"""Mixin for TypeVarLike defaults."""
__slots__ = ()
__init__ = _set_default
115
# Classes using this metaclass must provide a _backported_typevarlike ClassVar
class _TypeVarLikeMeta(type):
def __instancecheck__(cls, __instance: Any) -> bool:
return isinstance(__instance, cls._backported_typevarlike)
# Add default and infer_variance parameters from PEP 696 and 695
class TypeVar(metaclass=_TypeVarLikeMeta):
"""Type variable."""
_backported_typevarlike = typing.TypeVar
def __new__(cls, name, *constraints, bound=None,

covariant=False, contravariant=False,
default=_marker, infer_variance=False):
if hasattr(typing, "TypeAliasType"):
# PEP 695 implemented, can pass infer_variance to typing.TypeVar
typevar = typing.TypeVar(name, *constraints, bound=bound,
covariant=covariant, contravariant=contravariant,
infer_variance=infer_variance)
else:
typevar = typing.TypeVar(name, *constraints, bound=bound,
covariant=covariant, contravariant=contravariant)
if infer_variance and (covariant or contravariant):
raise ValueError("Variance cannot be specified with infer_variance.")
typevar.__infer_variance__ = infer_variance
_set_default(typevar, default)
_set_module(typevar)
return typevar
def __init_subclass__(cls) -> None:

raise TypeError(f"type '{__name__}.TypeVar' is not an acceptable base type")
# Python 3.10+ has PEP 612

if hasattr(typing, 'ParamSpecArgs'):
ParamSpecArgs = typing.ParamSpecArgs
ParamSpecKwargs = typing.ParamSpecKwargs
116
# 3.7-3.9
else:
class _Immutable:
"""Mixin to indicate that object should not be copied."""
__slots__ = ()
def __copy__(self):
return self
def __deepcopy__(self, memo):

return self
class ParamSpecArgs(_Immutable):
"""The args for a ParamSpec object.
Given a ParamSpec object P, P.args is an instance of ParamSpecArgs.
ParamSpecArgs objects have a reference back to their ParamSpec:
P.args.__origin__ is P
This type is meant for runtime introspection and has no special meaning to
static type checkers.
"""
def __init__(self, origin):
self.__origin__ = origin
def __repr__(self):
return f"{self.__origin__.__name__}.args"

if not isinstance(other, ParamSpecArgs):
return self.__origin__ == other.__origin__
class ParamSpecKwargs(_Immutable):
"""The kwargs for a ParamSpec object.
117
Given a ParamSpec object P, P.kwargs is an instance of ParamSpecKwargs.
ParamSpecKwargs objects have a reference back to their ParamSpec:
P.kwargs.__origin__ is P
This type is meant for runtime introspection and has no special meaning to
static type checkers.
"""
def __init__(self, origin):
def __repr__(self):
return f"{self.__origin__.__name__}.kwargs"

if not isinstance(other, ParamSpecKwargs):
return self.__origin__ == other.__origin__
# 3.10+
if hasattr(typing, 'ParamSpec'):
# Add default parameter - PEP 696

class ParamSpec(metaclass=_TypeVarLikeMeta):
"""Parameter specification."""
_backported_typevarlike = typing.ParamSpec
def __new__(cls, name, *, bound=None,

covariant=False, contravariant=False,
infer_variance=False, default=_marker):
# PEP 695 implemented, can pass infer_variance to typing.TypeVar
paramspec = typing.ParamSpec(name, bound=bound,
covariant=covariant,
contravariant=contravariant,
infer_variance=infer_variance)
else:
118
paramspec = typing.ParamSpec(name, bound=bound,
covariant=covariant,
contravariant=contravariant)
paramspec.__infer_variance__ = infer_variance
_set_default(paramspec, default)
_set_module(paramspec)
return paramspec
def __init_subclass__(cls) -> None:

raise TypeError(f"type '{__name__}.ParamSpec' is not an acceptable base
type")
# 3.7-3.9
else:
# Inherits from list as a workaround for Callable checks in Python < 3.9.2.
class ParamSpec(list, _DefaultMixin):
"""Parameter specification variable.
Usage::
P = ParamSpec('P')
Parameter specification variables exist primarily for the benefit of static

type checkers. They are used to forward the parameter types of one
callable to another callable, a pattern commonly found in higher order
functions and decorators. They are only valid when used in ``Concatenate``,
or s the first argument to ``Callable``.
In Python 3.10 and higher,

they are also supported in user-defined Generics at runtime.
See class Generic for more information on generic types. An
example for annotating a decorator::
T = TypeVar('T')
P = ParamSpec('P')
def add_logging(f: Callable[P, T]) -> Callable[P, T]:

119
'''A type-safe decorator to add logging to a function.'''
def inner(*args: P.args, **kwargs: P.kwargs) -> T:
logging.info(f'{f.__name__} was called')
return f(*args, **kwargs)
return inner
@add_logging
def add_two(x: float, y: float) -> float:
'''Add two numbers together.'''
return x + y
Parameter specification variables defined with covariant=True or

contravariant=True can be used to declare covariant or contravariant
generic types. These keyword arguments are valid, but their actual semantics
are yet to be decided. See PEP 612 for details.
Parameter specification variables can be introspected. e.g.:
P.__name__ == 'T'
P.__bound__ == None
P.__covariant__ == False
P.__contravariant__ == False
Note that only parameter specification variables defined in global scope can
be pickled.
"""
# Trick Generic __parameters__.

__class__ = typing.TypeVar
@property
def args(self):
return ParamSpecArgs(self)
@property
def kwargs(self):
return ParamSpecKwargs(self)
120
def __init__(self, name, *, bound=None, covariant=False, contravariant=False,
infer_variance=False, default=_marker):
super().__init__([self])
self.__name__ = name
self.__covariant__ = bool(covariant)
self.__contravariant__ = bool(contravariant)
self.__infer_variance__ = bool(infer_variance)
if bound:
self.__bound__ = typing._type_check(bound, 'Bound must be a type.')
else:
self.__bound__ = None
_DefaultMixin.__init__(self, default)
# for pickling:
def_mod = _caller()
self.__module__ = def_mod
def __repr__(self):
if self.__infer_variance__:
prefix = ''
elif self.__covariant__:
prefix = '+'
elif self.__contravariant__:
prefix = '-'
else:
prefix = '~'
return prefix + self.__name__
def __hash__(self):
return object.__hash__(self)

return self is other
return self.__name__
# Hack to get typing._type_check to pass.

121
def __call__(self, *args, **kwargs):
pass
# 3.7-3.9
if not hasattr(typing, 'Concatenate'):
# Inherits from list as a workaround for Callable checks in Python < 3.9.2.
class _ConcatenateGenericAlias(list):
# Trick Generic into looking into this for __parameters__.

__class__ = typing._GenericAlias
# Flag in 3.8.
_special = False
def __init__(self, origin, args):

super().__init__(args)
self.__args__ = args
def __repr__(self):
_type_repr = typing._type_repr
return (f'{_type_repr(self.__origin__)}'
f'[{", ".join(_type_repr(arg) for arg in self.__args__)}]')
def __hash__(self):
return hash((self.__origin__, self.__args__))
# Hack to get typing._type_check to pass in Generic.

def __call__(self, *args, **kwargs):
pass
@property
def __parameters__(self):
return tuple(
tp for tp in self.__args__ if isinstance(tp, (typing.TypeVar, ParamSpec))
)
122
# 3.7-3.9
@typing._tp_cache
def _concatenate_getitem(self, parameters):
if parameters == ():
raise TypeError("Cannot take a Concatenate of no types.")
if not isinstance(parameters[-1], ParamSpec):
raise TypeError("The last parameter to Concatenate should be a "
"ParamSpec variable.")
msg = "Concatenate[arg, ...]: each arg must be a type."
parameters = tuple(typing._type_check(p, msg) for p in parameters)
return _ConcatenateGenericAlias(self, parameters)
# 3.10+
if hasattr(typing, 'Concatenate'):
Concatenate = typing.Concatenate
_ConcatenateGenericAlias = typing._ConcatenateGenericAlias # noqa: F811
# 3.9
def Concatenate(self, parameters):
"""Used in conjunction with ``ParamSpec`` and ``Callable`` to represent a
higher order function which adds, removes or transforms parameters of a
callable.
For example::
Callable[Concatenate[int, P], int]
See PEP 612 for detailed information.

"""
return _concatenate_getitem(self, parameters)

# 3.7-8
else:
class _ConcatenateForm(_ExtensionsSpecialForm, _root=True):
123
return _concatenate_getitem(self, parameters)
Concatenate = _ConcatenateForm(
'Concatenate',
doc="""Used in conjunction with ``ParamSpec`` and ``Callable`` to represent a
higher order function which adds, removes or transforms parameters of a
callable.
For example::
Callable[Concatenate[int, P], int]
See PEP 612 for detailed information.

""")
# 3.10+
if hasattr(typing, 'TypeGuard'):
TypeGuard = typing.TypeGuard
# 3.9
def TypeGuard(self, parameters):
"""Special typing form used to annotate the return type of a user-defined
type guard function. ``TypeGuard`` only accepts a single type argument.
At runtime, functions marked this way should return a boolean.
``TypeGuard`` aims to benefit *type narrowing* -- a technique used by static

type checkers to determine a more precise type of an expression within a
program's code flow. Usually type narrowing is done by analyzing
conditional code flow and applying the narrowing to a block of code. The
conditional expression here is sometimes referred to as a "type guard".
Sometimes it would be convenient to use a user-defined boolean function

as a type guard. Such a function should use ``TypeGuard[...]`` as its
return type to alert static type checkers to this intention.
Using ``-> TypeGuard`` tells the static type checker that for a given
function:
1. The return value is a boolean.

124
2. If the return value is ``True``, the type of its argument
is the type inside ``TypeGuard``.
For example::
def is_str(val: Union[str, float]):

# "isinstance" type guard
if isinstance(val, str):
# Type of ``val`` is narrowed to ``str``
...
else:
# Else, type of ``val`` is narrowed to ``float``.
...
Strict type narrowing is not enforced -- ``TypeB`` need not be a narrower

form of ``TypeA`` (it can even be a wider form) and this may lead to
type-unsafe results. The main reason is to allow for things like
narrowing ``List[object]`` to ``List[str]`` even though the latter is not
a subtype of the former, since ``List`` is invariant. The responsibility of
writing type-safe type guards is left to the user.
``TypeGuard`` also works with type variables. For more information, see
PEP 647 (User-Defined Type Guards).
"""
item = typing._type_check(parameters, f'{self} accepts only a single type.')
# 3.7-3.8
else:
class _TypeGuardForm(_ExtensionsSpecialForm, _root=True):
f'{self._name} accepts only a single type')
TypeGuard = _TypeGuardForm(
'TypeGuard',
doc="""Special typing form used to annotate the return type of a user-defined

type guard function. ``TypeGuard`` only accepts a single type argument.
At runtime, functions marked this way should return a boolean.
125
``TypeGuard`` aims to benefit *type narrowing* -- a technique used by static
type checkers to determine a more precise type of an expression within a
program's code flow. Usually type narrowing is done by analyzing
conditional code flow and applying the narrowing to a block of code. The
conditional expression here is sometimes referred to as a "type guard".
Sometimes it would be convenient to use a user-defined boolean function

as a type guard. Such a function should use ``TypeGuard[...]`` as its
return type to alert static type checkers to this intention.
Using ``-> TypeGuard`` tells the static type checker that for a given
function:
1. The return value is a boolean.

2. If the return value is ``True``, the type of its argument
is the type inside ``TypeGuard``.
For example::
def is_str(val: Union[str, float]):

# "isinstance" type guard
if isinstance(val, str):
# Type of ``val`` is narrowed to ``str``
...
else:
# Else, type of ``val`` is narrowed to ``float``.
...
Strict type narrowing is not enforced -- ``TypeB`` need not be a narrower

form of ``TypeA`` (it can even be a wider form) and this may lead to
type-unsafe results. The main reason is to allow for things like
narrowing ``List[object]`` to ``List[str]`` even though the latter is not
a subtype of the former, since ``List`` is invariant. The responsibility of
writing type-safe type guards is left to the user.
``TypeGuard`` also works with type variables. For more information, see
PEP 647 (User-Defined Type Guards).
126
""")
# Vendored from cpython typing._SpecialFrom

class _SpecialForm(typing._Final, _root=True):
__slots__ = ('_name', '__doc__', '_getitem')
def __init__(self, getitem):

self._getitem = getitem
self._name = getitem.__name__
self.__doc__ = getitem.__doc__
def __getattr__(self, item):

if item in {'__name__', '__qualname__'}:
return self._name
raise AttributeError(item)
def __mro_entries__(self, bases):

raise TypeError(f"Cannot subclass {self!r}")
def __repr__(self):
return f'typing_extensions.{self._name}'
return self._name
def __call__(self, *args, **kwds):

raise TypeError(f"Cannot instantiate {self!r}")
def __or__(self, other):

return typing.Union[self, other]
def __ror__(self, other):

return typing.Union[other, self]
def __instancecheck__(self, obj):
raise TypeError(f"{self} cannot be used with isinstance()")

127
def __subclasscheck__(self, cls):
raise TypeError(f"{self} cannot be used with issubclass()")
@typing._tp_cache
return self._getitem(self, parameters)
if hasattr(typing, "LiteralString"):
LiteralString = typing.LiteralString
else:
@_SpecialForm
def LiteralString(self, params):
"""Represents an arbitrary literal string.
Example::
from typing_extensions import LiteralString
def query(sql: LiteralString) -> ...:

...
query("SELECT * FROM table") # ok

query(f"SELECT * FROM {input()}") # not ok
See PEP 675 for details.
"""
if hasattr(typing, "Self"):
Self = typing.Self
else:
@_SpecialForm
def Self(self, params):
"""Used to spell the type of "self" in classes.
128
Example::
from typing import Self
class ReturnsSelf:
def parse(self, data: bytes) -> Self:
...
return self
"""
if hasattr(typing, "Never"):
Never = typing.Never
else:
@_SpecialForm
def Never(self, params):
"""The bottom type, a type that has no members.
This can be used to define a function that should never be

called, or a function that never returns::
from typing_extensions import Never
def never_call_me(arg: Never) -> None:

pass
def int_or_str(arg: int | str) -> None:

never_call_me(arg) # type checker error
match arg:
case int():
print("It's an int")
case str():
print("It's a str")
case _:
never_call_me(arg) # ok, arg is of type Never
129
"""
if hasattr(typing, 'Required'):
Required = typing.Required
NotRequired = typing.NotRequired
def Required(self, parameters):
"""A special typing construct to mark a key of a total=False TypedDict
as required. For example:
class Movie(TypedDict, total=False):

title: Required[str]
year: int
m = Movie(
title='The Matrix', # typechecker error if key is omitted
year=1999,
)
There is no runtime checking that a required key is actually provided

when instantiating a related TypedDict.
"""
item = typing._type_check(parameters, f'{self._name} accepts only a single
type.')
def NotRequired(self, parameters):
"""A special typing construct to mark a key of a TypedDict as
potentially missing. For example:
class Movie(TypedDict):
title: str
year: NotRequired[int]
130
m = Movie(
year=1999,
)
"""
type.')
else:
class _RequiredForm(_ExtensionsSpecialForm, _root=True):
Required = _RequiredForm(
'Required',
doc="""A special typing construct to mark a key of a total=False TypedDict
as required. For example:
class Movie(TypedDict, total=False):

title: Required[str]
year: int
m = Movie(
year=1999,
)
There is no runtime checking that a required key is actually provided

when instantiating a related TypedDict.
""")
NotRequired = _RequiredForm(
'NotRequired',
doc="""A special typing construct to mark a key of a TypedDict as
potentially missing. For example:
131
title: str
year: NotRequired[int]
m = Movie(
year=1999,
)
""")
_UNPACK_DOC = """\
Type unpack operator.
The type unpack operator takes the child types from some container type,
such as `tuple[int, str]` or a `TypeVarTuple`, and 'pulls them out'. For
example:
# For some generic class `Foo`:

Foo[Unpack[tuple[int, str]]] # Equivalent to Foo[int, str]
Ts = TypeVarTuple('Ts')
# Specifies that `Bar` is generic in an arbitrary number of types.
# (Think of `Ts` as a tuple of an arbitrary number of individual
# `TypeVar`s, which the Ùnpack` is 'pulling out' directly into the
# `Generic[]`.)
class Bar(Generic[Unpack[Ts]]): ...
Bar[int] # Valid
Bar[int, str] # Also valid
From Python 3.11, this can also be done using the `*` operator:
Foo[*tuple[int, str]]
class Bar(Generic[*Ts]): ...
The operator can also be used along with a `TypedDict` to annotate

`**kwargs` in a function signature. For instance:
132
name: str
year: int
# This function expects two keyword arguments - *name* of type `str` and
# *year* of type ìnt`.
def foo(**kwargs: Unpack[Movie]): ...
Note that there is only some runtime checking of this operator. Not
everything the runtime allows may be accepted by static type checkers.
For more information, see PEP 646 and PEP 692.

"""
if sys.version_info >= (3, 12): # PEP 692 changed the repr of Unpack[]
Unpack = typing.Unpack
def _is_unpack(obj):
return get_origin(obj) is Unpack

class _UnpackSpecialForm(_ExtensionsSpecialForm, _root=True):
def __init__(self, getitem):
super().__init__(getitem)
self.__doc__ = _UNPACK_DOC
class _UnpackAlias(typing._GenericAlias, _root=True):

@_UnpackSpecialForm
def Unpack(self, parameters):
type.')
return _UnpackAlias(self, (item,))
return isinstance(obj, _UnpackAlias)
else:
class _UnpackAlias(typing._GenericAlias, _root=True):
133
class _UnpackForm(_ExtensionsSpecialForm, _root=True):

return _UnpackAlias(self, (item,))
Unpack = _UnpackForm('Unpack', doc=_UNPACK_DOC)
return isinstance(obj, _UnpackAlias)
if hasattr(typing, "TypeVarTuple"): # 3.11+
# Add default parameter - PEP 696

class TypeVarTuple(metaclass=_TypeVarLikeMeta):
"""Type variable tuple."""
_backported_typevarlike = typing.TypeVarTuple
def __new__(cls, name, *, default=_marker):

tvt = typing.TypeVarTuple(name)
_set_default(tvt, default)
_set_module(tvt)
return tvt
def __init_subclass__(self, *args, **kwds):

raise TypeError("Cannot subclass special typing classes")
else:
class TypeVarTuple(_DefaultMixin):
"""Type variable tuple.
Usage::
Ts = TypeVarTuple('Ts')
134
In the same way that a normal type variable is a stand-in for a single
type such as `ìnt``, a type variable *tuple* is a stand-in for a *tuple*
type such as ``Tuple[int, str]``.
Type variable tuples can be used in ``Generic`` declarations.

Consider the following example::
class Array(Generic[*Ts]): ...
The ``Ts`` type variable tuple here behaves like ``tuple[T1, T2]``,
where ``T1`` and ``T2`` are type variables. To use these type variables
as type parameters of `Àrray``, we must *unpack* the type variable tuple using
the star operator: ``*Ts``. The signature of `Àrray`` then behaves
as if we had simply written ``class Array(Generic[T1, T2]): ...``.
In contrast to ``Generic[T1, T2]``, however, ``Generic[*Shape]`` allows
us to parameterise the class with an *arbitrary* number of type parameters.
Type variable tuples can be used anywhere a normal ``TypeVar`` can.

This includes class definitions, as shown above, as well as function
signatures and variable annotations::
class Array(Generic[*Ts]):
def __init__(self, shape: Tuple[*Ts]):

self._shape: Tuple[*Ts] = shape
def get_shape(self) -> Tuple[*Ts]:

return self._shape
shape = (Height(480), Width(640))

x: Array[Height, Width] = Array(shape)
y = abs(x) # Inferred type is Array[Height, Width]
z=x+x # ... is Array[Height, Width]
x.get_shape() # ... is tuple[Height, Width]
"""
# Trick Generic __parameters__.

135
def __iter__(self):
yield self.__unpacked__
def __init__(self, name, *, default=_marker):
_DefaultMixin.__init__(self, default)
# for pickling:
def_mod = _caller()
self.__unpacked__ = Unpack[self]
def __repr__(self):
def __hash__(self):
return object.__hash__(self)

return self is other
def __init_subclass__(self, *args, **kwds):

if '_root' not in kwds:
raise TypeError("Cannot subclass special typing classes")
if hasattr(typing, "reveal_type"):
reveal_type = typing.reveal_type
else:
def reveal_type(__obj: T) -> T:
"""Reveal the inferred type of a variable.
When a static type checker encounters a call to ``reveal_type()``,

136
it will emit the inferred type of the argument::
x: int = 1
reveal_type(x)
Running a static type checker (e.g., ``mypy``) on this example

will produce output similar to 'Revealed type is "builtins.int"'.
At runtime, the function prints the runtime type of the

argument and returns it unchanged.
"""
print(f"Runtime type is {type(__obj).__name__!r}", file=sys.stderr)
return __obj
if hasattr(typing, "assert_never"):
assert_never = typing.assert_never
else:
def assert_never(__arg: Never) -> Never:
"""Assert to the type checker that a line of code is unreachable.
Example::
def int_or_str(arg: int | str) -> None:

match arg:
case int():
print("It's an int")
case str():
print("It's a str")
case _:
assert_never(arg)
If a type checker finds that a call to assert_never() is

reachable, it will emit an error.
At runtime, this throws an exception when called.
"""
raise AssertionError("Expected code to be unreachable")
137
# dataclass_transform exists in 3.11 but lacks the frozen_default parameter
dataclass_transform = typing.dataclass_transform
else:
def dataclass_transform(
*,
eq_default: bool = True,

order_default: bool = False,
kw_only_default: bool = False,
frozen_default: bool = False,
field_specifiers: typing.Tuple[
typing.Union[typing.Type[typing.Any], typing.Callable[..., typing.Any]],
...
] = (),
**kwargs: typing.Any,
) -> typing.Callable[[T], T]:
"""Decorator that marks a function, class, or metaclass as providing
dataclass-like behavior.
Example:
from typing_extensions import dataclass_transform
_T = TypeVar("_T")
# Used on a decorator function

@dataclass_transform()
def create_model(cls: type[_T]) -> type[_T]:
...
return cls
@create_model
class CustomerModel:
id: int
name: str
# Used on a base class

138
class ModelBase: ...
class CustomerModel(ModelBase):
id: int
name: str
# Used on a metaclass
class ModelMeta(type): ...
class ModelBase(metaclass=ModelMeta): ...
class CustomerModel(ModelBase):
id: int
name: str
Each of the ``CustomerModel`` classes defined in this example will now

behave similarly to a dataclass created with the ``@dataclasses.dataclass``
decorator. For example, the type checker will synthesize an ``__init__``
method.
The arguments to this decorator can be used to customize this behavior:

- `èq_default`` indicates whether the `èq`` parameter is assumed to be
True or False if it is omitted by the caller.
- `òrder_default`` indicates whether the `òrder`` parameter is
assumed to be True or False if it is omitted by the caller.
- ``kw_only_default`` indicates whether the ``kw_only`` parameter is
- ``frozen_default`` indicates whether the ``frozen`` parameter is
- ``field_specifiers`` specifies a static list of supported classes
or functions that describe fields, similar to ``dataclasses.field()``.
At runtime, this decorator records its arguments in the

``__dataclass_transform__`` attribute on the decorated object.
"""
def decorator(cls_or_fn):
cls_or_fn.__dataclass_transform__ = {
139
"eq_default": eq_default,
"order_default": order_default,
"kw_only_default": kw_only_default,
"frozen_default": frozen_default,
"field_specifiers": field_specifiers,
"kwargs": kwargs,
}
return cls_or_fn
return decorator
if hasattr(typing, "override"):
override = typing.override
else:
_F = typing.TypeVar("_F", bound=typing.Callable[..., typing.Any])
def override(__arg: _F) -> _F:

"""Indicate that a method is intended to override a method in a base class.
Usage:
class Base:
def method(self) -> None: ...
pass
class Child(Base):
@override
def method(self) -> None:
super().method()
When this decorator is applied to a method, the type checker will

validate that it overrides a method with the same name on a base class.
This helps prevent bugs that may occur when a base class is changed
without an equivalent change to a child class.
There is no runtime checking of these properties. The decorator

sets the ``__override__`` attribute to ``True`` on the decorated object
to allow runtime introspection.
140
"""
try:
__arg.__override__ = True
except (AttributeError, TypeError):
# Skip the attribute silently if it is not writable.
# AttributeError happens if the object has __slots__ or a
# read-only property, TypeError if it's a builtin class.
pass
return __arg
if hasattr(typing, "deprecated"):
deprecated = typing.deprecated
else:
_T = typing.TypeVar("_T")
def deprecated(
__msg: str,
*,
category: typing.Optional[typing.Type[Warning]] = DeprecationWarning,
stacklevel: int = 1,
) -> typing.Callable[[_T], _T]:
"""Indicate that a class, function or overload is deprecated.
Usage:
@deprecated("Use B instead")
class A:
pass
@deprecated("Use g instead")
def f():
pass
@overload
@deprecated("int support is deprecated")
def g(x: int) -> int: ...
@overload
def g(x: str) -> int: ...
141
When this decorator is applied to an object, the type checker
will generate a diagnostic on usage of the deprecated object.
The warning specified by ``category`` will be emitted on use

of deprecated objects. For functions, that happens on calls;
for classes, on instantiation. If the ``category`` is ``None``,
no warning is emitted. The ``stacklevel`` determines where the
warning is emitted. If it is ``1`` (the default), the warning
is emitted at the direct caller of the deprecated object; if it
is higher, it is emitted further up the stack.
The decorator sets the ``__deprecated__``

attribute on the decorated object to the deprecation message
passed to the decorator. If applied to an overload, the decorator
must be after the ``@overload`` decorator for the attribute to
exist on the overload as returned by ``get_overloads()``.
"""
def decorator(__arg: _T) -> _T:
if category is None:
__arg.__deprecated__ = __msg
return __arg
elif isinstance(__arg, type):
original_new = __arg.__new__
has_init = __arg.__init__ is not object.__init__
@functools.wraps(original_new)
warnings.warn(__msg, category=category, stacklevel=stacklevel + 1)
if original_new is not object.__new__:
return original_new(cls, *args, **kwargs)
# Mirrors a similar check in object.__new__.
elif not has_init and (args or kwargs):
raise TypeError(f"{cls.__name__}() takes no arguments")
else:
return original_new(cls)
142
__arg.__new__ = staticmethod(__new__)
__arg.__deprecated__ = __new__.__deprecated__ = __msg
return __arg
elif callable(__arg):
@functools.wraps(__arg)
def wrapper(*args, **kwargs):
warnings.warn(__msg, category=category, stacklevel=stacklevel + 1)
return __arg(*args, **kwargs)
__arg.__deprecated__ = wrapper.__deprecated__ = __msg

return wrapper
else:
raise TypeError(
"@deprecated decorator with non-None category must be applied to "
f"a class or callable, not {__arg!r}"
)
return decorator
# We have to do some monkey patching to deal with the dual nature of

# Unpack/TypeVarTuple:
# - We want Unpack to be a kind of TypeVar so it gets accepted in
# Generic[Unpack[Ts]]
# - We want it to *not* be treated as a TypeVar for the purposes of
# counting generic parameters, so that when we subscript a generic,
# the runtime doesn't try to substitute the Unpack with the subscripted type.
if not hasattr(typing, "TypeVarTuple"):
typing._collect_type_vars = _collect_type_vars
typing._check_generic = _check_generic
# Backport typing.NamedTuple as it exists in Python 3.12.

# In 3.11, the ability to define generic `NamedTuple`s was supported.
# This was explicitly disallowed in 3.9-3.10, and only half-worked in <=3.8.
# On 3.12, we added __orig_bases__ to call-based NamedTuples
# On 3.13, we deprecated kwargs-based NamedTuples
NamedTuple = typing.NamedTuple
143
else:
def _make_nmtuple(name, types, module, defaults=()):
fields = [n for n, t in types]
annotations = {n: typing._type_check(t, f"field {n} annotation must be a type")
for n, t in types}
nm_tpl = collections.namedtuple(name, fields,
defaults=defaults, module=module)
nm_tpl.__annotations__ = nm_tpl.__new__.__annotations__ = annotations
# The `_field_types` attribute was removed in 3.9;
# in earlier versions, it is the same as the `__annotations__` attribute
if sys.version_info < (3, 9):
nm_tpl._field_types = annotations
return nm_tpl
_prohibited_namedtuple_fields = typing._prohibited
_special_namedtuple_fields = frozenset({'__module__', '__name__',
'__annotations__'})
class _NamedTupleMeta(type):
def __new__(cls, typename, bases, ns):
assert _NamedTuple in bases
for base in bases:
if base is not _NamedTuple and base is not typing.Generic:
raise TypeError(
'can only inherit from a NamedTuple type and Generic')
bases = tuple(tuple if base is _NamedTuple else base for base in bases)
types = ns.get('__annotations__', {})
default_names = []
for field_name in types:
if field_name in ns:
default_names.append(field_name)
elif default_names:
raise TypeError(f"Non-default namedtuple field {field_name} "
f"cannot follow default field"
f"{'s' if len(default_names) > 1 else ''} "
f"{', '.join(default_names)}")
nm_tpl = _make_nmtuple(
typename, types.items(),
defaults=[ns[n] for n in default_names],
module=ns['__module__']
144
)
nm_tpl.__bases__ = bases
if typing.Generic in bases:
if hasattr(typing, '_generic_class_getitem'): # 3.12+
nm_tpl.__class_getitem__ =
classmethod(typing._generic_class_getitem)
else:
class_getitem = typing.Generic.__class_getitem__.__func__
nm_tpl.__class_getitem__ = classmethod(class_getitem)
# update from user namespace without overriding special namedtuple
attributes
for key in ns:
if key in _prohibited_namedtuple_fields:
raise AttributeError("Cannot overwrite NamedTuple attribute " + key)
elif key not in _special_namedtuple_fields and key not in nm_tpl._fields:

setattr(nm_tpl, key, ns[key])
if typing.Generic in bases:
nm_tpl.__init_subclass__()
return nm_tpl
_NamedTuple = type.__new__(_NamedTupleMeta, 'NamedTuple', (), {})
def _namedtuple_mro_entries(bases):
assert NamedTuple in bases
return (_NamedTuple,)
@_ensure_subclassable(_namedtuple_mro_entries)
def NamedTuple(__typename, __fields=_marker, **kwargs):
"""Typed version of namedtuple.
Usage::
class Employee(NamedTuple):
name: str
id: int
This is equivalent to::
Employee = collections.namedtuple('Employee', ['name', 'id'])

145
The resulting class has an extra __annotations__ attribute, giving a
dict that maps field names to types. (The field names are also in
the _fields attribute, which is part of the namedtuple API.)
An alternative equivalent functional syntax is also accepted::
Employee = NamedTuple('Employee', [('name', str), ('id', int)])

"""
if __fields is _marker:
if kwargs:
deprecated_thing = "Creating NamedTuple classes using keyword
arguments"
deprecation_msg = (
"{name} is deprecated and will be disallowed in Python {remove}. "
"Use the class-based or functional syntax instead."
)
else:
deprecated_thing = "Failing to pass a value for the 'fields' parameter"
example = f"`{__typename} = NamedTuple({__typename!r}, [])`"
deprecation_msg = (
"To create a NamedTuple class with 0 fields "
"using the functional syntax, "
"pass an empty list, e.g. "
) + example + "."
elif __fields is None:
if kwargs:
raise TypeError(
"Cannot pass `None` as the 'fields' parameter "
"and also specify fields using keyword arguments"
)
else:
deprecated_thing = "Passing `None` as the 'fields' parameter"
example = f"`{__typename} = NamedTuple({__typename!r}, [])`"
deprecation_msg = (
"To create a NamedTuple class with 0 fields "
"using the functional syntax, "
"pass an empty list, e.g. "
) + example + "."
146
elif kwargs:
raise TypeError("Either list of fields or keywords"
" can be provided to NamedTuple, not both")
if __fields is _marker or __fields is None:
warnings.warn(
deprecation_msg.format(name=deprecated_thing, remove="3.15"),
DeprecationWarning,
stacklevel=2,
)
__fields = kwargs.items()
nt = _make_nmtuple(__typename, __fields, module=_caller())
nt.__orig_bases__ = (NamedTuple,)
return nt
# On 3.8+, alter the signature so that it matches typing.NamedTuple.

# The signature of typing.NamedTuple on >=3.8 is invalid syntax in Python 3.7,
# so just leave the signature as it is on 3.7.

_new_signature = '(typename, fields=None, /, **kwargs)'
if isinstance(NamedTuple, _types.FunctionType):
NamedTuple.__text_signature__ = _new_signature
else:
NamedTuple.__call__.__text_signature__ = _new_signature
if hasattr(collections.abc, "Buffer"):
Buffer = collections.abc.Buffer
else:
class Buffer(abc.ABC):
"""Base class for classes that implement the buffer protocol.
The buffer protocol allows Python objects to expose a low-level

memory buffer interface. Before Python 3.12, it is not possible
to implement the buffer protocol in pure Python code, or even
to check whether a class implements the buffer protocol. In
Python 3.12 and higher, the ``__buffer__`` method allows access
to the buffer protocol from Python code, and the
``collections.abc.Buffer`` ABC allows checking whether a class
implements the buffer protocol.
147
To indicate support for the buffer protocol in earlier versions,
inherit from this ABC, either in a stub file or at runtime,
or use ABC registration. This ABC provides no methods, because
there is no Python-accessible methods shared by pre-3.12 buffer
classes. It is useful primarily for static checks.
"""
# As a courtesy, register the most common stdlib buffer classes.

Buffer.register(memoryview)
Buffer.register(bytearray)
Buffer.register(bytes)
# Backport of types.get_original_bases, available on 3.12+ in CPython

if hasattr(_types, "get_original_bases"):
get_original_bases = _types.get_original_bases
else:
def get_original_bases(__cls):
"""Return the class's "original" bases prior to modification by
`__mro_entries__`.
Examples::
from typing import TypeVar, Generic

from typing_extensions import NamedTuple, TypedDict
T = TypeVar("T")
class Foo(Generic[T]): ...
class Bar(Foo[int], float): ...
class Baz(list[str]): ...
Eggs = NamedTuple("Eggs", [("a", int), ("b", str)])
Spam = TypedDict("Spam", {"a": int, "b": str})
assert get_original_bases(Bar) == (Foo[int], float)

assert get_original_bases(Baz) == (list[str],)
assert get_original_bases(Eggs) == (NamedTuple,)
assert get_original_bases(Spam) == (TypedDict,)
148
assert get_original_bases(int) == (object,)
"""
try:
return __cls.__orig_bases__
try:
return __cls.__bases__
raise TypeError(
f'Expected an instance of type, not {type(__cls).__name__!r}'
) from None
# NewType is a class on Python 3.10+, making it pickleable

# The error message for subclassing instances of NewType was improved on 3.11+
NewType = typing.NewType
else:
class NewType:
"""NewType creates simple unique types with almost zero
runtime overhead. NewType(name, tp) is considered a subtype of tp
by static type checkers. At runtime, NewType(name, tp) returns
a dummy callable that simply returns its argument. Usage::
UserId = NewType('UserId', int)
def name_by_id(user_id: UserId) -> str:
...
UserId('user') # Fails type check
name_by_id(42) # Fails type check
name_by_id(UserId(42)) # OK
num = UserId(5) + 1 # type: int
"""
def __call__(self, obj):

return obj
def __init__(self, name, tp):

self.__qualname__ = name
if '.' in name:
149
name = name.rpartition('.')[-1]
self.__supertype__ = tp
def_mod = _caller()
def __mro_entries__(self, bases):

# We defined __mro_entries__ to get a better error message
# if a user attempts to subclass a NewType instance. bpo-46170
supercls_name = self.__name__
class Dummy:
def __init_subclass__(cls):
subcls_name = cls.__name__
raise TypeError(
f"Cannot subclass an instance of NewType. "
f"Perhaps you were looking for: "
f"`{subcls_name} = NewType({subcls_name!r}, {supercls_name})`"
)
return (Dummy,)
def __repr__(self):
return f'{self.__module__}.{self.__qualname__}'
return self.__qualname__

# PEP 604 methods
# It doesn't make sense to have these methods on Python <3.10
def __or__(self, other):

return typing.Union[self, other]
def __ror__(self, other):

return typing.Union[other, self]
150
TypeAliasType = typing.TypeAliasType
else:
def _is_unionable(obj):
"""Corresponds to is_unionable() in unionobject.c in CPython."""
return obj is None or isinstance(obj, (
type,
_types.GenericAlias,
_types.UnionType,
TypeAliasType,
))
class TypeAliasType:
"""Create named, parameterized type aliases.
This provides a backport of the new `type` statement in Python 3.12:
type ListOrSet[T] = list[T] | set[T]
is equivalent to:
T = TypeVar("T")
ListOrSet = TypeAliasType("ListOrSet", list[T] | set[T], type_params=(T,))
The name ListOrSet can then be used as an alias for the type it refers to.
The type_params argument should contain all the type parameters used
in the value of the type alias. If the alias is not generic, this
argument is omitted.
Static type checkers should only support type aliases declared using
TypeAliasType that follow these rules:
- The first argument (the name) must be a string literal.

- The TypeAliasType instance must be immediately assigned to a variable
of the same name. (For example, 'X = TypeAliasType("Y", int)' is invalid,
as is 'X, Y = TypeAliasType("X", int), TypeAliasType("Y", int)').
"""
151
def __init__(self, name: str, value, *, type_params=()):
if not isinstance(name, str):
raise TypeError("TypeAliasType name must be a string")
self.__value__ = value
self.__type_params__ = type_params
parameters = []
for type_param in type_params:
if isinstance(type_param, TypeVarTuple):
parameters.extend(type_param)
else:
parameters.append(type_param)
self.__parameters__ = tuple(parameters)
def_mod = _caller()
# Setting this attribute closes the TypeAliasType from further modification
def __setattr__(self, __name: str, __value: object) -> None:

if hasattr(self, "__name__"):
self._raise_attribute_error(__name)
super().__setattr__(__name, __value)
def __delattr__(self, __name: str) -> Never:

self._raise_attribute_error(__name)
def _raise_attribute_error(self, name: str) -> Never:

# Match the Python 3.12 error messages exactly
if name == "__name__":
raise AttributeError("readonly attribute")
elif name in {"__value__", "__type_params__", "__parameters__",
"__module__"}:
raise AttributeError(
f"attribute '{name}' of 'typing.TypeAliasType' objects "
"is not writable"
)
else:
raise AttributeError(
152
f"'typing.TypeAliasType' object has no attribute '{name}'"
)
def __repr__(self) -> str:


parameters = [
typing._type_check(
item, f'Subscripting {self.__name__} requires a type.'
)
for item in parameters
]
return typing._GenericAlias(self, tuple(parameters))

raise TypeError(
"type 'typing_extensions.TypeAliasType' is not an acceptable base type"
)
# The presence of this method convinces typing._type_check

# that TypeAliasTypes are types.
def __call__(self):
raise TypeError("Type alias is not callable")

def __or__(self, right):
# For forward compatibility with 3.12, reject Unions
# that are not accepted by the built-in Union.
if not _is_unionable(right):
return typing.Union[self, right]
153
def __ror__(self, left):
if not _is_unionable(left):
return typing.Union[left, self]
if hasattr(typing, "is_protocol"):
is_protocol = typing.is_protocol
get_protocol_members = typing.get_protocol_members
else:
def is_protocol(__tp: type) -> bool:
"""Return True if the given type is a Protocol.
Example::
>>> from typing_extensions import Protocol, is_protocol

>>> class P(Protocol):
... def a(self) -> str: ...
... b: int
>>> is_protocol(P)
True
>>> is_protocol(int)
False
"""
return (
isinstance(__tp, type)
and getattr(__tp, '_is_protocol', False)
and __tp is not Protocol
and __tp is not getattr(typing, "Protocol", object())
)
def get_protocol_members(__tp: type) -> typing.FrozenSet[str]:

"""Return the set of members defined in a Protocol.
Example::
>>> from typing_extensions import Protocol, get_protocol_members

154
>>> class P(Protocol):
... def a(self) -> str: ...
... b: int
>>> get_protocol_members(P)
frozenset({'a', 'b'})
Raise a TypeError for arguments that are not Protocols.

"""
if not is_protocol(__tp):
raise TypeError(f'{__tp!r} is not a Protocol')
if hasattr(__tp, '__protocol_attrs__'):
return frozenset(__tp.__protocol_attrs__)
return frozenset(_get_protocol_attrs(__tp))
# Aliases for items that have always been in typing.

# Explicitly assign these (rather than using `from typing import *` at the top),
# so that we get a CI error if one of these is deleted from typing.py
# in a future version of Python
AbstractSet = typing.AbstractSet
AnyStr = typing.AnyStr
BinaryIO = typing.BinaryIO
Callable = typing.Callable
Collection = typing.Collection
Container = typing.Container
Dict = typing.Dict
ForwardRef = typing.ForwardRef
FrozenSet = typing.FrozenSet
Generator = typing.Generator
Generic = typing.Generic
Hashable = typing.Hashable
IO = typing.IO
ItemsView = typing.ItemsView
Iterable = typing.Iterable
Iterator = typing.Iterator
KeysView = typing.KeysView
List = typing.List
Mapping = typing.Mapping
155
MappingView = typing.MappingView
Match = typing.Match
MutableMapping = typing.MutableMapping
MutableSequence = typing.MutableSequence
MutableSet = typing.MutableSet
Optional = typing.Optional
Pattern = typing.Pattern
Reversible = typing.Reversible
Sequence = typing.Sequence
Set = typing.Set
Sized = typing.Sized
TextIO = typing.TextIO
Tuple = typing.Tuple
Union = typing.Union
ValuesView = typing.ValuesView
cast = typing.cast
no_type_check = typing.no_type_check
no_type_check_decorator = typing.no_type_check_decorator
156
5) Testing
5.1) Test Strategy/ Test Case
Developing a robust test strategy for DevSearch involves ensuring that

all aspects of the platform, including its modules and features, are
thoroughly tested to deliver a high-quality user experience. Here's a
detailed test strategy for DevSearch:
1. Requirement Analysis:
- Understand the functional and non-functional requirements of DevSearch.
- Analyze user stories, use cases, and acceptance criteria to define test
scenarios.
2. Test Planning:
- Define testing objectives, scope, and timelines.
- Allocate resources, including testing environments, tools, and team members.
- Determine testing techniques and methodologies, such as manual testing,
automated testing, and exploratory testing.
3. Test Environment Setup:

- Set up testing environments that replicate the production environment,
including servers, databases, and network configurations.
- Ensure that test environments are isolated from production to prevent any
impact on live users.
4. Test Case Design:

- Create comprehensive test cases covering functional, non-functional, and edge
cases.
- Include positive and negative test scenarios to validate expected behavior and
error handling.
- Define test data and inputs required for executing test cases.
157
5. Functional Testing:
- Conduct functional testing to verify that all features and modules of
DevSearch work as intended.
- Test search functionality, user authentication, profile management,
documentation access, community interaction, and recommendation engine.
- Verify integration with external tools and platforms for seamless
interoperability.
6. Usability Testing:
- Evaluate the user interface, navigation flow, and overall user experience of
DevSearch.
- Test accessibility, responsiveness, and compatibility across different devices
and browsers.
- Gather feedback from real users to identify usability issues and areas for
improvement.
7. Performance Testing:
- Perform load testing, stress testing, and scalability testing to assess the
performance of DevSearch under various conditions.
- Measure response times, throughput, and resource utilization to identify
performance bottlenecks.
- Optimize system architecture and configurations to ensure optimal
performance and responsiveness.
8. Security Testing:
- Conduct security testing to identify vulnerabilities and ensure data protection.
- Test authentication mechanisms, authorization controls, data encryption, and
secure communication protocols.
- Perform penetration testing and vulnerability scanning to uncover potential
security risks.
158
9. Compatibility Testing:
- Verify compatibility with different operating systems, browsers, and devices.
- Test DevSearch on various platforms to ensure consistent functionality and
user experience across different environments.
10. Regression Testing:

- Implement regression testing to validate that new updates or fixes do not
introduce regressions or break existing functionality.
- Automate regression test cases to streamline the testing process and ensure
consistent test coverage.
11. Monitoring and Reporting:

- Monitor test execution progress and collect metrics on test coverage, defect
density, and test effectiveness.
- Generate test reports summarizing test results, findings, and recommendations
for stakeholders.
- Communicate testing progress and any identified risks or issues to the
development team and project stakeholders.
12. Feedback and Iteration:

- Gather feedback from users and stakeholders based on testing results and user
acceptance.
- Iterate on the development of DevSearch, addressing identified issues,
implementing enhancements, and continuously improving the platform based on
user feedback.
By following this comprehensive test strategy, DevSearch can ensure the

reliability, performance, security, and usability of its platform, delivering a
seamless experience for developers worldwide.
159
6) Future Enhancement
-Certainly! Here are some potential future enhancements for

DevSearch:
1. Advanced Search Filters:

Implement more advanced search filters to allow users to refine their
search results by factors such as programming language version, release
date, popularity, and community rating.
2. Interactive Tutorials:
Integrate interactive tutorials and coding exercises directly into
DevSearch to provide hands-on learning experiences for users, helping
them learn new technologies more effectively.
3. Real-time Collaboration: Enable real-time collaboration features,

such as live coding sessions, pair programming, and code reviews, to
facilitate teamwork and knowledge sharing among developers.
4. Integration with Learning Platforms: Partner with online learning

platforms and MOOCs (Massive Open Online Courses) to integrate
educational content directly into DevSearch, allowing users to
seamlessly access tutorials, courses, and certification programs.
5. Code Playground: Create a code playground within DevSearch

where users can experiment with code snippets, test algorithms, and
prototype ideas without leaving the platform.
6. Personalized Learning Paths: Implement personalized learning

paths based on users' skill levels, interests, and learning goals, providing
curated recommendations and resources to help users progress in their
programming journey.
160
7. Code Analysis and Debugging Tools: Integrate code analysis tools
and debugging utilities into DevSearch to help developers identify and
fix issues in their code more efficiently.
8. Machine Learning-Powered Recommendations: Utilize machine

learning algorithms to improve the accuracy of content
recommendations, leveraging user behavior data and contextual
information to suggest relevant resources and topics.
9. Offline Access: Develop offline access capabilities, allowing users to

download documentation, tutorials, and other resources for offline
viewing and reference, enhancing accessibility and convenience.
10. Community Events and Workshops: Host virtual community

events, workshops, and webinars directly within DevSearch, providing
opportunities for developers to network, learn from industry experts, and
collaborate on projects.
11. Internationalization and Localization: Expand support for multiple

languages and regions to make DevSearch more accessible to developers
worldwide, including localized content, interfaces, and community
forums.
12. Accessibility Features: Improve accessibility features within

DevSearch to ensure that the platform is usable by all users, including
those with disabilities, by adhering to accessibility standards and
guidelines.
13. Blockchain Integration for Trust and Transparency: Explore the

integration of blockchain technology to enhance trust and transparency
within the developer community, such as verifying the authenticity of
code snippets, tutorials, and credentials.
These enhancements can help elevate DevSearch into a more

comprehensive and valuable platform for developers, offering a wide
range of tools, resources, and collaborative features to support their
161
learning and productivity needs.
7) Screenshot:-
Home page
162
Profile page
163
Message page
164
Project page
165
About the page
166
Login page
167
168
8) Bibliography
Online Resources:
TensorFlow Documentation:
https://www.tensorflow.org/ OpenCV Documentation:
https://docs.opencv.org/
GitHub Repositories:
GitHub - OpenCV: https://github.com/opencv/opencv
GitHub - TensorFlow:
https://github.com/tensorflow/tensorflow Tutorials and
169

Devsearch Synopsis

Uploaded by

Copyright:

Available Formats

Devsearch Synopsis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Devsearch Synopsis

Uploaded by

Copyright:

Available Formats

“Devsearch”

MAJOR PROJECT REPORT (KCA-451)

DR. A.P.J. ABDUL KALAM TECHNICAL UNIVERSITY, LUCKNOW

FOR THE PARTIAL FULFILLMENT OF THE DEGREE OF MASTER

IN COMPUTER APPLICATION SESSION (2022-24)

Under the Guidance of Submitted by:

Prof. Mr. Shailender Vats Naina Sharma (2200980140026)

INSTITUTE OF MANAGEMENT STUDIES, NOIDA

For Office Use Only:

Signature of the Mentor

Approved Not Approved Date:

Suggestions (if any):-

S.No. Description Page No.

I am very grateful to my Major project (KCA-451) Mr. Shailender Vats, for

1.1 Project Definition

Techopedia explains the Devsearch Meaning

At its core, DevSearch functions as a centralized hub where developers can

One of the key features of DevSearch is its advanced search functionality.

In addition to traditional search functionality, DevSearch incorporates AI-powered

DevSearch also fosters collaboration and networking within the developer

1.3.1) Existing System:

The existing system of DevSearch comprises a user-friendly platform that

1. User Profiles: Developers create detailed profiles showcasing their skills,

2. Advanced Search: Employers can utilize various filters to narrow down

3. AI-Powered Recommendations: DevSearch employs recommendation

4. Collaboration Tools: Developers can connect with each other, share

5. Streamlined Hiring Process: Employers can manage job postings,

Overall, the existing system of DevSearch provides a comprehensive

The work environment at DevSearch is characterized by innovation, collaboration,

1. Innovative Culture: DevSearch fosters an environment that encourages

2. Collaborative Atmosphere: Collaboration is at the heart of DevSearch's work

3. Tech-Focused: As a tech-driven company, DevSearch places a strong

4. Agile Methodology: DevSearch embraces agile methodologies in its

5. Remote Work Culture: DevSearch embraces remote work culture, providing

Overall, the work environment at DevSearch is dynamic, collaborative, and

1. Finding the Right Talent:

2. Navigating a Fragmented Landscape:

3. Lack of Visibility for Developers:

4. Tedious Hiring Processes:

5. Limited Networking Opportunities:

Absolutely, let's delve into each need of DevSearch in detail:

1. Efficient Talent Acquisition: DevSearch addresses the need for companies to

2. Comprehensive Developer Profiles: Developers need a platform to create

4. Advanced Search Capabilities: DevSearch offers advanced search filters that

5. Proactive Talent Recommendations: DevSearch's recommendation algorithms

6. Collaboration Tools: Developers require tools to connect, communicate, and

8. Remote Work Support: With the increasing prevalence of remote work,

9. Continuous Learning Resources: DevSearch offers a wide range of resources

10. Networking Opportunities: DevSearch facilitates networking opportunities

12. Feedback and Review Mechanism: DevSearch incorporates a feedback and

15. Career Growth Opportunities: Developers seek opportunities for career

1.6.1) Proposed System:

1. Enhanced User Profiles: Developers can create more comprehensive profiles,

2. Improved Search Functionality: The search functionality is enhanced with

3. AI-Powered Candidate Matching: DevSearch incorporates advanced AI

4. Integrated Coding Assessments: The platform integrates coding assessment

6. Automated Interview Scheduling: DevSearch automates the interview

7. Enhanced Privacy Controls: Developers have greater control over the

8. Community Q&A Forum: DevSearch introduces a community Q&A forum

- Increased Visibility: DevSearch provides developers with a platform to