পাইথন ফাইলগুলির সাধারণ শিরোনাম ফর্ম্যাটটি কী?

508

পাইথন কোডিং নির্দেশিকা সম্পর্কে ডকুমেন্টে পাইথন উত্স ফাইলগুলির জন্য নিম্নলিখিত শিরোনাম ফর্ম্যাটটি জুড়ে এসেছি:

#!/usr/bin/env python

"""Foobar.py: Description of what foobar does."""

__author__      = "Barack Obama"
__copyright__   = "Copyright 2009, Planet Earth"

এটি কি পাইথন বিশ্বে শিরোলেখগুলির মানক বিন্যাস? আমি শিরোনামে অন্য কোন ক্ষেত্র / তথ্য রাখতে পারি? পাইথন গুরুগুলি ভাল পাইথন উত্স শিরোলেখগুলির জন্য আপনার নির্দেশিকা ভাগ করে:

python header comments

— আশ্বিন নানজাপ্পা
সূত্র

এখানে শুরু করার জন্য একটি ভাল জায়গা: পিইপি 257 , যা ডকাস্ট্রিংস সম্পর্কে কথা বলে এবং অন্যান্য বেশ কয়েকটি প্রাসঙ্গিক নথির লিঙ্ক।

— পিটার

41

এই প্রশ্নের পৃথক পৃথক উত্তর পড়তে তাদের জন্য সম্ভবত একটি দরকারী গাইডলাইন হ'ল তারা এই ফাইলের শিরোনামগুলি কী উদ্দেশ্যে ব্যবহার করবে বলে বিবেচনা করে। যদি আপনার কোনও কংক্রিট ব্যবহারের মামলা থাকে (যেমন আমার আইনজীবী বলেছেন যে আদালত মামলাগুলি হারিয়ে গেছে কারণ বিকাশকারীরা প্রতিটি ফাইলে কপিরাইটের তথ্য রাখতে ব্যর্থ হন)) তবে সেই ব্যবহারের ক্ষেত্রে আপনার প্রয়োজনীয় তথ্য যুক্ত করুন এবং বজায় রাখুন। অন্যথায়, আপনি কেবল নিজের ওসিডি ফেটিশকে নিযুক্ত করছেন।

— জোনাথন হার্টলে

হা হা গ্রেট @ জোনাথন হার্টলি! আমার নিজের প্রকল্পগুলির জন্য, আপনি যেমনটি লিখেছেন "আমি আমার ওসিডি ফেটিশকে নিযুক্ত করি।" hahaaha stackoverflow.com/a/51914806/1896134

— JayRizzo

577

এটি Foobarমডিউলটির জন্য সমস্ত মেটাডেটা ।

প্রথমটি হল docstringমডিউলটির, এটি ইতিমধ্যে পিটারের উত্তরে ব্যাখ্যা করা হয়েছে ।

আমি কীভাবে আমার মডিউলগুলি (উত্স ফাইলগুলি) সংগঠিত করব? (আর্কাইভ)

প্রতিটি ফাইলের প্রথম লাইন চিত্কার করা উচিত #!/usr/bin/env python। এটি স্ক্রিপ্ট হিসাবে দাতব্যকে অন্তর্নিহিতভাবে অনুরোধ করে ফাইল চালানো সম্ভব করে তোলে, যেমন একটি সিজিআই প্রসঙ্গে।

এরপরে বর্ণনার সাথে ডকাস্ট্রিং হওয়া উচিত। যদি বিবরণটি দীর্ঘ হয় তবে প্রথম লাইনে একটি সংক্ষিপ্তসার হওয়া উচিত যা নিজস্বভাবে বোঝায়, একটি নতুন লাইনের মাধ্যমে বাকী থেকে পৃথক।

আমদানি বিবৃতি সহ সমস্ত কোডের ডকস্ট্রিং অনুসরণ করা উচিত। অন্যথায়, দস্তাবেজ দোভাষী দ্বারা স্বীকৃত হবে না, এবং ইন্টারেক্টিভ সেশনে (যেমন মাধ্যমে obj.__doc__) বা স্বয়ংক্রিয় সরঞ্জামগুলির সাথে ডকুমেন্টেশন তৈরি করার সময় আপনার এতে অ্যাক্সেস থাকবে না ।

প্রথমে অন্তর্নির্মিত মডিউলগুলি আমদানি করুন, তৃতীয় পক্ষের মডিউলগুলি অনুসরণ করুন, তারপরে পাথ এবং আপনার নিজস্ব মডিউলগুলিতে কোনও পরিবর্তন হবে। বিশেষত, আপনার মডিউলগুলির পথ এবং নামগুলির সংযোজন দ্রুত পরিবর্তন হওয়ার সম্ভাবনা রয়েছে: এগুলিকে এক জায়গায় রাখলে তাদের সন্ধান করা সহজ হয়।

পরবর্তী লেখকের তথ্য হওয়া উচিত। এই তথ্যের এই ফর্ম্যাটটি অনুসরণ করা উচিত:
__author__ = "Rob Knight, Gavin Huttley, and Peter Maxwell"
__copyright__ = "Copyright 2007, The Cogent Project"
__credits__ = ["Rob Knight", "Peter Maxwell", "Gavin Huttley",
                    "Matthew Wakefield"]
__license__ = "GPL"
__version__ = "1.0.1"
__maintainer__ = "Rob Knight"
__email__ = "rob@spot.colorado.edu"
__status__ = "Production"
স্থিতি সাধারণত "প্রোটোটাইপ", "বিকাশ" বা "উত্পাদন" এর মধ্যে একটি হওয়া উচিত। __maintainer__সেই ব্যক্তি হওয়া উচিত যা বাগগুলি সংশোধন করবে এবং আমদানি করা হলে উন্নতি করবে। __credits__এর মধ্যে পৃথক পৃথক লোকগুলির __author__মধ্যে __credits__রয়েছে যারা বাগ ফিক্স রিপোর্ট করেছেন, পরামর্শ দিয়েছেন ইত্যাদি কিন্তু আসলে কোডটি লেখেন নি।

এখানে আপনি আরও তথ্য তালিকা আছে, __author__, __authors__, __contact__, __copyright__, __license__, __deprecated__, __date__এবং __version__হিসাবে স্বীকৃত মেটাডেটা।

— Esteban Küber
সূত্র

7

শিরোনাম তথ্য তৈরি করা কোনওভাবে নতুন ফাইলগুলির জন্য স্বয়ংক্রিয় করা যেতে পারে?

— Hauke

184

আমি মনে করি আমদানির পরে এই সমস্ত মেটাডেটা একটি খারাপ ধারণা। এই মেটাডেটার অংশগুলি যা একটি একক ফাইলে প্রয়োগ হয় (যেমন লেখক, তারিখ) ইতিমধ্যে উত্স নিয়ন্ত্রণ দ্বারা ট্র্যাক করা হয়েছে। ফাইলটিতে একই তথ্যের অনুলিপি এবং অতিক্রান্ত অনুলিপি দেওয়া আমার কাছে ভুল বলে মনে হচ্ছে। পুরো প্রকল্পের জন্য প্রয়োগ করা অংশগুলি (যেমন লাইসেন্স, সংস্করণ) প্রতিটি উত্স কোড ফাইলের পরিবর্তে তাদের নিজস্ব ফাইলটিতে কোনও প্রকল্প পর্যায়ে আরও ভাল অবস্থিত বলে মনে হয়।

— জোনাথন হার্টলি

28

জোনাথন হার্টলির সাথে পুরোপুরি সম্মত হন। কোডটির উত্তরাধিকারী পরবর্তী ব্যক্তির তিনটি পছন্দ রয়েছে: 1) কোডটি সম্পাদনা করার সময় সমস্ত সময় এটি আপডেট করুন 2) এটিকে একা রেখে দিন, এটির ক্ষেত্রে এটি ভুল হবে 3) এটি সমস্ত মুছুন। বিকল্প 1 তাদের সময় নষ্ট করা, বিশেষত যেহেতু তাদের একেবারে শূন্যের আস্থা রয়েছে যে তারা মেটাডেটা এটি গ্রহণ করার সময় আপ টু ডেট ছিল। বিকল্প 2 এবং 3 এর অর্থ এই যে সেখানে আপনার প্রথম স্থানটিতে রাখার সময় নষ্ট হয়েছিল। সমাধান: প্রত্যেকের সময় বাঁচান এবং এটি সেখানে রাখবেন না।

— spookylukey

77

বেশিরভাগ পাইথন ফাইলের শেবাং লাইন থাকার কোনও কারণ নেই।

— মাইক গ্রাহাম

15

প্রতি পিইপি 8, এর __version__আগে এবং পরে একটি ফাঁকা রেখা সহ সরাসরি প্রধান ডকাস্ট্রিং অনুসরণ করা দরকার। এছাড়াও শেবাংয়ের আওতায় আপনার চরসেটটি তাত্ক্ষণিক সংজ্ঞায়িত করা ভাল অনুশীলন -# -*- coding: utf-8 -*-

— ডেভ ল্যাসলে

179

আমি দৃ file়ভাবে ন্যূনতম ফাইল শিরোলেখকে সমর্থন করি, যার দ্বারা আমি ঠিক বলতে চাইছি:

#!যদি এটি এক্সিকিউটেবল স্ক্রিপ্ট হয় তবে হ্যাশবাং ( লাইন)
মডিউল ডক্ট্রিং
আমদানি, স্ট্যান্ডার্ড পদ্ধতিতে গোষ্ঠীযুক্ত, যেমন:

  import os    # standard library
  import sys

  import requests  # 3rd party packages

  import mypackage.mymodule  # local source
  import mypackage.myothermodule

অর্থাত। তাদের মধ্যে একক ফাঁকা রেখা সহ তিনটি আমদানি গোষ্ঠী। প্রতিটি গ্রুপের মধ্যে, আমদানি বাছাই করা হয়। স্থানীয় উত্স থেকে আমদানি করা চূড়ান্ত গোষ্ঠী হয় প্রদর্শিত হিসাবে নিরঙ্কুশ আমদানি হতে পারে, বা সুস্পষ্ট আপেক্ষিক আমদানি হতে পারে।

বাকি সমস্ত কিছুই সময়, দর্শনীয় স্থানের অপচয় এবং সক্রিয়ভাবে বিভ্রান্তিকর।

আপনার যদি আইনী অস্বীকৃতি বা লাইসেন্সিং তথ্য থাকে তবে এটি একটি পৃথক ফাইলে যায়। এটিতে প্রতিটি উত্স কোড ফাইল সংক্রামিত হওয়ার দরকার নেই। আপনার কপিরাইটটি এর অংশ হওয়া উচিত। লোকেদের এটিকে LICENSEএলোমেলো উত্স কোড নয়, আপনার ফাইলে এটি সন্ধান করতে হবে।

মেটাডেটা যেমন লেখকতা এবং তারিখগুলি ইতিমধ্যে আপনার উত্স নিয়ন্ত্রণ দ্বারা রক্ষণাবেক্ষণ করা হয়। ফাইলটিতে একই তথ্যের একটি কম-বিশদ, ভুল, এবং অতিক্রান্ত সংস্করণ যুক্ত করার প্রয়োজন নেই।

আমি বিশ্বাস করি না যে অন্য যে কোনও ডেটা রয়েছে যা প্রত্যেককে তাদের সমস্ত উত্স ফাইলগুলিতে লাগাতে হবে। এটি করার জন্য আপনার কিছু নির্দিষ্ট প্রয়োজন থাকতে পারে, তবে এই জিনিসগুলি কেবলমাত্র আপনার জন্য সংজ্ঞা অনুসারে প্রযোজ্য। "প্রত্যেকের জন্য প্রস্তাবিত সাধারণ শিরোনাম" এগুলির কোনও স্থান নেই।

— জোনাথন হার্টলি
সূত্র

23

আরও সম্মত হতে পারিনি - একাধিক জায়গায় কোড প্রতিলিপি করা একটি পাপ তাই শিরোনাম তথ্যের জন্য কেন একই কাজ করা। এটিকে একটি এক জায়গায় রাখুন (প্রকল্পের মূল) এবং অনেক, অনেকগুলি ফাইল জুড়ে এই জাতীয় তথ্য বজায় রাখার ঝামেলা এড়ান।

— গ্রামীণ

13

যদিও আমি সম্মত হই যে উত্স নিয়ন্ত্রণ আরও বৈধ লেখকতার তথ্য সরবরাহ করতে ঝোঁক, কখনও কখনও লেখক কেবলমাত্র সংগ্রহস্থলকে অ্যাক্সেস না দিয়ে উত্স বিতরণ করে, বা সম্ভবত বিতরণ কাজটি যেমন, উদাহরণস্বরূপ: পাইপি থেকে কেন্দ্রিয় ইনস্টলেশন। সুতরাং, মডিউল শিরোনাম হিসাবে লেখক তথ্য এম্বেড এখনও উপকারী।

— pram

6

আরে প্রম আমি সত্যিই দরকারী যেখানে একটি ব্যবহারের ক্ষেত্রে কল্পনা করতে সমস্যা হচ্ছে। আমি সামগ্রিকভাবে প্রকল্পের জন্য লেখক সম্পর্কিত তথ্য জানতে চাইছেন এমন কোনও ব্যক্তি কল্পনা করতে পারেন এবং তারা একটি কেন্দ্রীয় কেন্দ্রে বড় অবদানকারীদের তালিকা থেকে মূল্য পেতে পারে, সম্ভবত প্রকল্পটির পুনঃনির্মাণ বা ডক্স রয়েছে। তবে (ক) স্বতন্ত্র ফাইলগুলির রচয়িতা জানতে চান এবং (খ) উত্স রেপোতে অ্যাক্সেস থাকবে না এবং (গ) এই তথ্যটি ভুল ছিল কিনা তা জানার উপায় নেই বা এ সম্পর্কে কোন যত্ন নেই or তারিখের বাইরে?

— জোনাথন হার্টলি

12

অনেক লাইসেন্সের জন্য আপনাকে খুব ভাল কারণে প্রতিটি ফাইলে লাইসেন্সের বয়লারপ্লেট অন্তর্ভুক্ত করতে হবে। যদি কেউ ফাইল বা দু'একটি নিয়ে যায় এবং লাইসেন্স ব্যতীত এগুলিকে পুনরায় বিতরণ করে তবে এটি প্রাপ্ত লোকেরা কোন লাইসেন্সের অধীনে তা জানেনা এবং তাদের এটি সন্ধান করতে হবে (ধরে নিলে তারা ভাল বিশ্বাসে রয়েছেন, এটি হ'ল)।

— nyuszika7h

3

__version__যদিও প্রচুর মডিউল (স্কিপি, নম্পি, ম্যাটপ্লোটলিব) মেটাডেটা রয়েছে, এবং আমি মনে করি এটি করা ভাল, যেহেতু এটি প্রোগ্রামগুলিতে অ্যাক্সেসযোগ্য এবং ইন্টারেক্টিভ ইন্টারপ্রেটারে দ্রুত পরীক্ষা করা উচিত। যদিও লেখকতা এবং আইনী তথ্য একটি আলাদা ফাইলে অন্তর্ভুক্ত। যদি না আপনার জন্য একটি ব্যবহারের ক্ষেত্রে আছেif 'Rob' in __author__:

— endolith

34

উপরের উত্তরগুলি সত্যিই সম্পূর্ণ, তবে আপনি যদি অনুলিপি করে পেস্টের অনুলিপি এবং নোংরা শিরোনাম চান তবে এটি ব্যবহার করুন:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""Module documentation goes here
   and here
   and ...
"""

কেন এটি একটি ভাল:

প্রথম লাইনটি * নিক্স ব্যবহারকারীদের জন্য। এটি ব্যবহারকারীর পথে পাইথন ইন্টারপ্রেটারকে বেছে নেবে, সুতরাং স্বয়ংক্রিয়ভাবে ব্যবহারকারী পছন্দের অনুবাদককে বেছে নেবে।
দ্বিতীয়টি হ'ল ফাইল এনকোডিং। আজকাল প্রতিটি ফাইলের অবশ্যই একটি এনকোডিং যুক্ত থাকতে হবে। ইউটিএফ -8 সর্বত্র কাজ করবে। কেবলমাত্র উত্তরাধিকার প্রকল্পগুলি অন্যান্য এনকোডিং ব্যবহার করবে।
এবং একটি খুব সাধারণ ডকুমেন্টেশন। এটি একাধিক লাইন পূরণ করতে পারে।

আরও দেখুন: https://www.python.org/dev/peps/pep-0263/

আপনি যদি প্রতিটি ফাইলে কেবল একটি ক্লাস লিখেন তবে আপনার ডকুমেন্টেশনও লাগবে না (এটি ক্লাস ডকের অভ্যন্তরে যাবে)।

— Neves
সূত্র

5

> "আজকাল প্রতিটি ফাইলের অবশ্যই একটি এনকোডিং যুক্ত থাকতে হবে।" এটি বিভ্রান্তিকর বলে মনে হচ্ছে। utf8 হ'ল ডিফল্ট এনকোডিং, সুতরাং এটি নির্দিষ্ট না করার জন্য এটি পুরোপুরি ঠিক।

— জোনাথন হার্টলি

23

আপনি যদি অ-এসকিআই অক্ষর ব্যবহার করে থাকেন তবে পিইপি 263 দেখুন

বিমূর্ত

এই পিইপি পাইথন উত্স ফাইলের এনকোডিং ঘোষণার জন্য একটি সিনট্যাক্স প্রবর্তনের প্রস্তাব করেছে। তারপরে এনকোডিং তথ্য পাইথন পার্সার দ্বারা প্রদত্ত এনকোডিং ব্যবহার করে ফাইলটি ব্যাখ্যা করতে ব্যবহৃত হয়। সর্বাধিক উল্লেখযোগ্যভাবে এটি সোর্স কোডে ইউনিকোড লিটারালগুলির ব্যাখ্যাকে বাড়িয়ে তোলে এবং ইউনিকোড লিটারালগুলি উদাহরণস্বরূপ ইউটিএফ -8 ব্যবহার করে সরাসরি কোনও ইউনিকোড সচেতন সম্পাদকের মাধ্যমে লেখা সম্ভব করে তোলে।

সমস্যা

পাইথন ২.১-তে, ইউনিকোড লিটারালগুলি কেবল লাতিন -1 ভিত্তিক এনকোডিং "ইউনিকোড-এস্কেপ" ব্যবহার করে রচনা করা যায়। এটি পাইথন ব্যবহারকারীদের কাছে প্রোগ্রামিংয়ের পরিবেশটিকে বন্ধুত্বপূর্ণ করে তোলে যারা এশিয়ার অনেক দেশের মতো নন-ল্যাটিন -1 লোকালয়ে বাস করে এবং কাজ করে। প্রোগ্রামাররা পছন্দসই এনকোডিং ব্যবহার করে তাদের 8-বিট স্ট্রিং লিখতে পারে, তবে ইউনিকোড লিটারালগুলির জন্য "ইউনিকোড-এস্কেপ" এনকোডিংয়ের সাথে আবদ্ধ।

প্রস্তাবিত সমাধান

আমি পাইথন উত্স কোড এনকোডিং ঘোষণার জন্য ফাইলের শীর্ষে একটি বিশেষ মন্তব্য ব্যবহার করে প্রতি উত্স ফাইলের ভিত্তিতে দৃশ্যমান এবং পরিবর্তনযোগ্য উভয়ই এনকোডিং করার প্রস্তাব করছি।

পাইথনকে এই এনকোডিং ঘোষণার বিষয়ে সচেতন করতে পাইথনের উত্স কোডের ডেটা হ্যান্ডলিংয়ের ক্ষেত্রে প্রচুর ধারণা পরিবর্তন প্রয়োজন।

এনকোডিং সংজ্ঞায়িত করা হচ্ছে

যদি অন্য কোনও এনকোডিংয়ের ইঙ্গিত না দেওয়া হয় তবে পাইথন ASCII এ স্ট্যান্ডার্ড এনকোডিং হিসাবে ডিফল্ট হবে।

উত্স কোড এনকোডিং সংজ্ঞায়িত করার জন্য, একটি যাদু মন্তব্য অবশ্যই উত্স ফাইলগুলিতে ফাইলের প্রথম বা দ্বিতীয় লাইন হিসাবে স্থাপন করা উচিত, যেমন:
      # coding=<encoding name>
বা (জনপ্রিয় সম্পাদক দ্বারা স্বীকৃত ফর্ম্যাটগুলি ব্যবহার করে)
      #!/usr/bin/python
      # -*- coding: <encoding name> -*-
অথবা
      #!/usr/bin/python
      # vim: set fileencoding=<encoding name> :
...

— জন লা রো
সূত্র

15

এটি লক্ষণীয় যে পাইথন 3 যেহেতু, ডিফল্ট অক্ষর সেটটি ইউটিএফ -8।

— nyuszika7h