.webp 이미지를 .png로 변환하는 Python 프로그램을 작성할 수 있습니다. 이를 위해 Pillow 라이브러리를 사용합니다. Pillow는 Python의 이미지 처리 라이브러리로, 다양한 이미지 형식을 다룰 수 있습니다.
다음은 특정 폴더 내의 모든 .webp 이미지를 .png로 변환하는 프로그램입니다:
1. Pillow 설치
먼저 Pillow 라이브러리를 설치해야 합니다. 터미널이나 명령 프롬프트에서 다음 명령어를 실행하세요:
pip install Pillow
2. .webp 이미지를 .png로 변환하는 코드
아래 코드 예시는 지정된 폴더 내의 모든 .webp 파일을 .png 파일로 변환합니다:
from PIL import Image
import os
def convert_webp_to_png(folder_path):
# 폴더 내 모든 파일을 반복
for filename in os.listdir(folder_path):
if filename.endswith(".webp"):
# 파일의 전체 경로 생성
webp_file_path = os.path.join(folder_path, filename)
# .webp 파일을 열고 .png로 저장
png_filename = filename[:-5] + ".png" # 파일 확장자를 .png로 변경
png_file_path = os.path.join(folder_path, png_filename)
with Image.open(webp_file_path) as img:
img.save(png_file_path, "png")
print(f"Converted: '{filename}' -> '{png_filename}'")
# 사용 예시
folder_path = 'path_to_your_folder' # 여기에 폴더 경로를 입력하세요
convert_webp_to_png(folder_path)
코드 설명
Pillow 라이브러리 사용: Pillow의 Image 모듈을 사용하여 이미지를 열고 변환합니다.
폴더 내 파일 탐색:
os.listdir(folder_path)를 사용하여 지정된 폴더 내의 모든 파일을 가져옵니다.
if filename.endswith(".webp"): 조건문을 사용하여 .webp 확장자를 가진 파일만 필터링합니다.
파일 경로 생성:
webp_file_path는 원본 .webp 파일의 전체 경로입니다.
png_filename은 .webp 확장자를 .png로 대체한 새 파일 이름입니다.
png_file_path는 변환된 .png 파일의 전체 경로입니다.
이미지 변환 및 저장:
Image.open(webp_file_path)를 사용하여 .webp 파일을 열고, img.save(png_file_path, "png")를 사용하여 .png 파일로 저장합니다.
사용 방법:
folder_path 변수에 변환할 .webp 파일이 있는 폴더 경로를 입력합니다.
프로그램을 실행하면 폴더 내 모든 .webp 파일이 .png 파일로 변환됩니다.
사용 예시
예를 들어, 폴더 경로가 C:/Users/YourName/Documents/Images인 경우:
공백( ) 또는 하이픈(-)을 언더바(_)로 변경하는 프로그램을 작성할 수 있습니다. 이 프로그램은 지정된 폴더 내 모든 파일의 이름을 확인하고, 공백 또는 하이픈이 포함된 경우 이를 언더바로 대체하여 이름을 변경합니다.
import os
def replace_spaces_and_hyphens_in_filenames(folder_path):
# 폴더 내 모든 파일을 반복
for filename in os.listdir(folder_path):
# 파일의 전체 경로 생성
old_file_path = os.path.join(folder_path, filename)
# 파일 이름에 공백 또는 하이픈이 있는지 확인
if ' ' in filename or '-' in filename:
# 공백과 하이픈을 언더바로 대체
new_filename = filename.replace(' ', '_').replace('-', '_')
new_file_path = os.path.join(folder_path, new_filename)
# 파일 이름 변경
os.rename(old_file_path, new_file_path)
print(f"Renamed: '{filename}' -> '{new_filename}'")
else:
print(f"No change: '{filename}'")
# 사용 예시
folder_path = 'path_to_your_folder' # 여기에 폴더 경로를 입력하세요
replace_spaces_and_hyphens_in_filenames(folder_path)
프로그램 설명
os 모듈: 파일 경로와 관련된 작업을 수행하기 위해 os 모듈을 사용합니다.
폴더 내 파일 탐색:
os.listdir(folder_path)를 사용하여 지정된 폴더 내의 모든 파일 및 하위 디렉토리 이름을 가져옵니다.
for filename in os.listdir(folder_path)를 사용하여 각 파일을 순회합니다.
공백과 하이픈을 언더바로 변경:
if ' ' in filename or '-' in filename: 조건문을 사용하여 파일 이름에 공백 또는 하이픈이 포함되어 있는지 확인합니다.
filename.replace(' ', '_').replace('-', '_')를 사용하여 공백과 하이픈을 언더바로 대체합니다.
파일 이름 변경:
os.rename(old_file_path, new_file_path)를 사용하여 파일 이름을 변경합니다.
사용 방법:
folder_path에 파일 이름을 변경할 폴더의 경로를 입력합니다.
프로그램을 실행하면 폴더 내 모든 파일의 이름에서 공백과 하이픈이 언더바로 변경됩니다.
사용 예시
폴더 경로를 지정하여 프로그램을 실행하면, 그 폴더 안의 모든 파일 이름에서 공백 또는 하이픈이 언더바로 변경됩니다. 예를 들어, path_to_your_folder가 C:/Users/YourName/Documents/TestFolder인 경우:
August Headline: Python is chasing Java's TIOBE index records
This month, Python has a ranking of more than 18% for the first time in its history. The last time a language hit more than 18% was Java in November 2016. Java is also the language with the highest ranking ever: 26.49% in June 2001. Runner up C++ is now exactly 8% behind Python, and that difference between position #1 and position #2 is also almost a record. The highest difference ever between position #1 and position #2 was in November 2016 when Java was 9.55% ahead of C. In summary, Python's hegemony is now undeniable. It is likely that it is Python's next step to become the most popular programming language ever. Is there any new language expected to come close to Python soon? Possible contenders Rust and Kotlin are approaching the TIOBE index top 10 fast, but it will take a lot of time before they become a real threat to Python. --Paul Jansen CEO TIOBE Software
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular web sites Google, Amazon, Wikipedia, Bing and more than 20 others are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here.
파이썬은 2024년 8월 티오베(Tiobe)의 프로그래밍 언어 인기 지수에서 역대 최고 평점인 18.04%를 기록했다. 이로써 파이썬은 2016년 11월 자바 이후 처음으로 18%에 도달한 언어가 됐다. 최고 기록은 자바가 2001년 6월에 세운 26.49%이다.
현재 파이썬은 2021년 10월에 처음으로 1위에 오르며 티오베 지수의 최상위 언어로 확고히 자리 잡았다. 티오베의 CEO 폴 얀센은 "파이썬의 상승은 주로 소프트웨어 엔지니어에 대한 수요가 많고 파이썬이 가장 배우기 쉬운 성숙한 범용 프로그래밍 언어이기 때문이다. 그래서 이 분야의 모든 초보자는 파이썬으로 시작한다"고 설명했다.
2024년 8월 티오베 지수에서 파이썬은 10.04%의 2위 C++보다 8%나 앞서 있다. 3위와 4위는 C 언어와 자바로 각각 각각 9.17%와 9.16%를 기록했다. 지난달 13위로 역대 최고 순위를 기록했던 러스트 언어는 다시 14위로 하락했다. 얀센은 "러스트의 하락에 대해 걱정할 필요 없다. 다음 달에는 다시 상승할 것”이라고 예측했다.
티오베 지수의 공식 명칭은 '티오베 프로그래밍 커뮤니티 지수(Tiobe Programming Community Index)'로, 구글, 빙, 아마존, 위키피디아 등의 웹사이트를 통해 전 세계 숙련된 엔지니어수, 강좌, 서드파티 솔루션 업체 등을 기반으로 월간 지수를 산출해 인기를 평가한다.
2024년 8월 티오베 지수의 상위 10개 언어는 다음과 같다:
파이썬 18.04%
C++ 10.04%
C 9.17%
자바 9.16%
C# 6.39%
자바스크립트 3.91%
SQL 2.21%
비주얼 베이직 2.18%
구글 고 2.03%
포트란 1.79%
파이선은 8월 파이플 프로그래밍 언어 인기 지수(Pypl Popularity of Programming Language index)에서도 파이썬이 1위 언어 자리를 굳건히 지키고 있다. Pypl 지수는 구글에서 언어가 얼마나 자주 검색되는지 분석하여 인기도를 평가한다. 2024년 8월 파이플 지수의 상위 10개 언어는 다음과 같다.
자바스크립트는 세계에서 가장 성공적이고 다재다능한 프로그래밍 언어 중 하나지만 처음부터 그랬던 것은 아니다. 지금의 자바스크립트는 자바스크립트를 만든 사람들이 원래 구상했던 언어와 완전히 다른 언어다. 그 11가지 이유를 살펴보자.
1995년 큰 꿈을 갖고 모인 소수의 프로그래머들이 자바스크립트를 출범했다. 원래 이들이 생각했던 이름은 모카(Mocha)나 라이브스크립트(LiveScript)였지만 유행에 밝았던 몇 사람이 이미 상당한 인기를 끌고 있던 자바 언어의 시류에 올라타기로 했다.
새로운 스크립팅 언어의 처음 목표는 단순해서, 정적 웹 페이지에 생명력을 좀 불어넣자는 것이었다. (당시 웹 페이지에서 움직이는 부분은 <blink> 태그밖에 없었다. 이 태그는 오래전에 사라졌지만 아직 기억하는 사람이 있을 것이다.) 그때 자바스크립트 개발자는 양식 요소를 이중으로 확인하기 위해 만들어진 아주 작은 레이어 하나가 이후 소프트웨어 배포의 주된 방식이 될 것이라고는 꿈에도 생각하지 못했을 것이다. 현재의 자바스크립트 버전에서는 이 1세대 스크립팅 언어의 흔적을 거의 찾아볼 수 없다. 오래된 코드도 대부분 웹사이트에서 여전히 실행되지만 초창기부터 지금까지 수많은 기능과 레이어가 추가됐다. 자바스크립트의 역할과 책임의 범위도 훨씬 더 커졌다. Node.js 덕분에 자바스크립트는 웹 페이지 전용을 넘어 서버측 스택의 큰 부분을 차지하면서 이제 <blink> 태그 또는 고양이 밈과는 아무런 관계도 없는 코드를 실행하고 있다. 암호화폐 애플리케이션, 의료, 주식거래 봇을 비롯한 수많은 작업이 자바스크립트에 의존한다. 30주년을 눈앞에 둔 자바스크립트 언어가 그 사이 얼마나 변했는지 돌아보자. 지금 우리가 사용하는 자바스크립트는 다음과 같은 11가지 측면에서 이 언어를 만든 이들과 초기 도입자들이 상상했던 언어와 완전히 다르다.
더 이상 자바스크립트로 불리지 않음
처음에는 모두가 자바스크립트라고 불렀다. 지금도 대부분의 개발자가 이 이름을 사용한다. 그러나 표준을 만드는 사람들이 공식적으로 사용하는 이름은 ECMA스크립트다. 일부는 규범적 언어 사양의 공식 버전 번호(최대 14)까지 명시한다. ECMA스크립트는 입에 잘 붙지 않고 따뜻한 커피를 연상시키지도 않지만 자바스크립트를 자바와 확실히 구분해준다. 이 이름을 사용함으로써 자바스크립트 개발자는 자바 상표, 로고 또는 기타 트레이드 드레스에 대해 걱정할 필요가 없다. 단, 이 사양을 유지관리 주체인 ECMA 인터내셔널(ECMA International)은 이름 옆에 작은 등록 상표 기호를 붙이는 것을 좋아한다는 점만(ECMAScript®) 예외적으로 주의하면 된다.
너무 방대해서 특정 부분의 전문화 필요
지금의 자바스크립트는 너무 방대해서 누구도, 심지어 매일 자바스크립트를 사용하는 개발자라 해도 모든 부분을 아는 것은 불가능하다. 서버 측 옵션과 동형(isomorphic) 코드의 등장으로 새로운 에너지가 유입되고 많은 개발이 이뤄져 한 사람이 브라우저 또는 서버를 위한 코드 작성의 세세한 부분을 모두 알기가 극히 어려워졌다.
이론적으로는 브라우저와 서버에서 모두 실행되는 코드를 쓸 수 있지만 현실에서 개발자는 브라우저 또는 서버 하나에 대한 전문성을 갖추는 데 집중한다. 개발자는 흔히 자신이 브라우저 기반 자바스크립트 프레임워크, 서버 측 자바스크립트, 또는 데이터베이스 측 자바스크립트를 다룬다고 구분해서 말한다. 자바스크립트 세계는 방대하다.
관건은 프레임워크
서버 세계와 브라우저 세계로 나누는 것 외에도 자바스크립트 개발자는 프레임워크 단위로 자신의 전문 분야를 좁히는 경향이 있다. 많은 구인 공고는 "자바스크립트" 프로그래머를 구하지 않는다. 이들은 리액트, 앵귤러를 비롯해 많이 사용되는 10여 개의 자바스크립트 프레임워크를 다룰 줄 아는 사람을 찾는다. 실용적인 결정이다.
프로그래머는 성공하려면 이러한 프레임워크의 세세한 특성에 정통해야 한다. 물론 자바스크립트의 기본도 알아야 한다. 그러나 앵귤러가 HTML 속성을 어떻게 사용하는지 모른다면 자바스크립트 전문 지식을 아무리 많이 갖고 있어도 도움이 되지 않는다. 앵귤러, 리액트와 같은 대형 프레임워크도 너무 커지고 복잡해져서 일부 프로그래머는 상태 관리 툴(리덕스(Redux), 몹액스(MobX)) 또는 기본 모델 옵션과 같은 자바스크립트의 하위 영역에 집중하는 더 작은 툴에 대한 전문성을 키우고 있다.
동형
자바스크립트의 인기가 큰 폭으로 늘어난 계기 중 하나는 Node.js를 통해 서버에서 실행되는 자바스크립트 코드를 작성할 수 있게 된 것이다. 한 팀이 브라우저 소프트웨어를 처리하고 다른 팀이 서버 측을 관리할 필요가 갑자기 사라졌다. 동일한 코드를 두 위치에서 동형으로 실행할 수 있게 되면서 자바스크립트 개발자는 브라우저에서 서버로, 다시 브라우저로 훨씬 더 쉽게 함수를 옮길 수 있게 됐다.
잠깐, 조금 전에 자바스크립트 세계가 두 갈래, 세 갈래 또는 그 이상으로 분화되고 있다고 말하지 않았던가? 맞다. 그러나 동형성은 여전히 가치 있다. 암호화와 같은 작업을 위한 많은 기본적인 함수는 다양한 영역에서 동일하게 실행이 가능하다. 물론 프로그래머는 한 틈새 영역에 대한 전문성을 키울 수 있지만 코드 자체는 모든 틈새 간에 아무런 제한 없이 흐를 수 있다.
다수의 새로운 연산자
원래의 자바스크립트에는 데이터 객체를 다루기 위한 간단한 기능이 몇 가지 있었다. 최신 버전은 데이터 구조를 분할하고 쪼개고 확장하고 변경할 수 있는 스프레드 연산자(…), map과 같은 추가 기능을 지원한다. 그 결과 매우 간결하면서도 매우 강력한 코드를 얻을 수 있다. 프로그래머는 복잡한 데이터 구조를 포장하고 풀기 위한 끝없는 루틴을 쓰지 않고도 손쉽게 이러한 구조를 제공할 수 있다. 코드는 더 간소하고 빠르며, 새로운 구문을 안다면 읽기도 더 쉽다.
모든 곳에 있는 JSON
초기 자바스크립트 프로그래머는 데이터를 공유하려면 파싱하고 직렬화할 수밖에 없었다. 이후 어느 영리한 사람이 네이티브 자바스크립트 객체 형식(JavaScript Object Notation, 즉 JSON)이 효율적인 동시에 속도도 빠르다는 사실을 발견했다. 자바스크립트 스택은 JSON을 사용해 저장된 데이터를 다른 대부분의 형식보다 더 빠르게 파싱할 수 있었다. 지금은 자바스크립트 코드를 쓰지 않는 프로그래머도 유연성과 효율성을 이유로 JSON 형식의 데이터를 사용한다. JSON은 모든 곳에 사용되지만, JSON을 빠르게 파싱하고 객체로 변환하는 자바스크립트 환경에 사용될 때 가장 잘 맞는 느낌이다.
빌드와 빌드 툴
초기 사람들은 텍스트 편집기로 자바스크립트를 쓰고 브라우저에서 테스트했다. 현대 자바스크립트 애플리케이션은 조금 더 복잡하다. 대부분의 경우 그런트(Grunt), 걸프(Gulp), 웹팩(Webpack)과 같이 다양한 구성요소를 최종 실행 스택으로 엮어주는 다단계 빌드 툴이 필요하다. 많은 개발자가 결국 코드를 테스트하고 충돌 가능성이 있는 버그를 확인하는 전체 CI/CD 서버를 사용하게 된다. 자바스크립트의 빌드 툴은 매우 강력해서 개발자와 일종의 애증의 관계에 있는 경우가 많다. 이들이 작성하는 코드는 분석을 거쳐 실제로 실행되는 형식으로 어셈블링되기 전까지는 아무 데서도 실행되지 않는다. 기술적으로 자바스크립트는 여전히 동적 스크립팅 언어지만 오래된 C 컴파일러보다 빌드에 더 오랜 시간이 걸리는 경우가 종종 있다.
JIT 컴파일
지금은 처리와 전처리가 스택의 위아래에서 이뤄진다. JIT(Just-In-Time) 컴파일러는 처음 등장할 때부터 자바스크립트의 잠재력을 끌어냈고 지금도 계속 개선되고 있다. 현재의 컴파일러는 코드가 실행될 때 반복적으로 이를 분석해서 대부분의 작업을 수행하는 알고리즘의 핵심 부분을 개선할 수 있을 만큼 똑똑하다. 가비지 수집에서 효과적이며 피해를 입히는 여러 가지 동작을 차단한다. 스크립팅 언어로 시작된 언어임을 감안하고 보면 자바스크립트의 JIT 레이어는 공식적으로 "컴파일되는" 언어만큼 강력해 보인다.
형식 안전성
자바스크립트 초창기 일부 프로그래머는 각 변수에 저장되는 데이터의 형식을 정의하기 위해 부가적인 입력이 필요하다는 점을 싫어했다. 여전히 기본 자바스크립트를 사용한다 해도 자유지만 이제는 상당히 많은 개발자가 타입스크립트와 기타 자바스크립트를 위한 형식 지정 옵션을 수용하고 있다. 이러한 프리프로세서는 형식 규칙, 그리고 이 규칙에 수반되는 모든 안전 장치를 적용한다.
방대한 라이브러리 생태계
오늘날 자바스크립트 생태계에는 폭과 깊이를 가늠하기 어려울 정도로 방대한 라이브러리가 번성 중이다. 수천, 수백만 가지의 애플리케이션을 위한 코드가 있다. 기본적인 프로젝트를 위한 빌드 파일도 수백 가지의 종속성을 가져올 수 있다. 자바스크립트는 깃허브, 깃랩 등의 리포지토리에서 가장 인기 있는 언어 중 하나다. 리포지토리에서 모든 경우에 맞는 코드를 며칠이고 탐색할 수 있다.
자바스크립트로 크로스 컴파일되는 다른 언어
자바스크립트의 최근 변화 하나를 꽂바면 다른 언어로 작성된 코드 지원이다. 자바스크립트로 크로스 컴파일해서 브라우저 또는 서버에서 실행할 수 있는 언어는 수백 가지에 이른다.
JIT 컴파일러 덕분에 이제 자바스크립트는 오래된 코볼 또는 새로운 하스켈을 어디서나 빠르게 실행하고자 하는 개발자에게 좋은 중간 지점 역할을 한다. 물론 이러한 언어를 좋아하는 사용자는 자체 컴파일러를 만들 수 있지만 자바스크립트로 크로스 컴파일해서 툴에 최적화를 맡기는 편이 더 쉽다. 결과적으로 많은 자바스크립트 코드가 완전히 다른 언어를 사용하는 프로그래머에 의해 작성됐다.
소규모 농업자도 사이버 공격에서 자유롭지 않다. 스위스의 한 낙농업자가 랜섬웨어 공격으로 인해 소 한 마리를 폐사한 것으로 알려졌다. 컴퓨터가 마비돼 소의 중요한 생체 데이터를 확인할 수 없었기 때문이다. 스위스 매체 루체너 차이퉁(Luzerner Zeitung)은 스위스 주크주의 낙농업자 비탈 버처는 최근 착유 로봇과 연결된 컴퓨터 시스템이 사이버 공격을 당했다고 최근 보도했다. 이 공격으로 결국 버처의 소 한 마리가 폐사했다고 매체는 전했다.
처음에 버처는 젖소의 착유 데이터가 더 이상 수신되지 않아 정전을 의심했다. 그러던 중 착유 시스템 제조업체로부터 해킹을 당했다는 경고를 받았다. 공격에는 버처의 착유 데이터를 잠그는 랜섬웨어가 포함돼 있었고, 공격자는 암호 해독을 위해 1만 달러(약 1,378만 원)를 요구했다.
처음에 버처는 공격자의 몸값 요구에 응해야 할지 고민했다. 하지만 주크 호수의 북쪽 한편에서 낙농장을 운영하는 버처에게는 우유 생산량에 대한 데이터가 긴급한 정보는 아니었다. 또한 착유 로봇은 정전 시에도 컴퓨터나 네트워크 연결 없이도 작동하기 때문에 착유 작업에는 문제가 없었다.
하지만 버처는 컴퓨터 시스템을 통해 동물의 생체 데이터를 수신한다. 소가 임신했을 때는 이런 데이터가 특히 중요하다. 버처의 동물 중 한 마리가 자궁 속에 죽은 송아지를 품고 있었고, 버처는 컴퓨터가 작동하지 않아 이런 응급 상황을 제때 인지하지 못했다. 버처는 스위스 언론과의 인터뷰에서 "어미를 구하기 위해 모든 노력을 다했지만 결국 포기해야만 했다"라고 말했다.
버처는 사이버 공격으로 인한 피해를 약 6,000 스위스 프랑(약 961만 원)으로 추산했다. 주로 수의사 비용과 새로운 컴퓨터 구매에 들어간 비용이다. 공격자에게 몸값을 지불하지는 않은 것으로 알려졌다.
