Đôi khi cách tốt nhất để gỡ lỗi nội dung nào đó là in một số nội dung vào trang và exit(), làm cách nào tôi có thể thực hiện việc này trong trang web Python/Django?Tương đương với PHP "echo something; exit();" với Python/Django?
ví dụ: trong PHP:
echo $var;
exit();
Cảm ơn
Đặt này trong chức năng xem của bạn:
from django.http import HttpResponse
return HttpResponse(str(var))
Tôi đang cố gắng thực hiện điều này từ lớp Middleware' process_request', vì vậy hãy quay lại một HttpResponse tại thời điểm đó sẽ không hoạt động, phải không? – adamJLev
Trên thực tế nó, sau khi đọc tài liệu Django nó trông giống như nếu bạn trả lại một HttpRequest, nó dừng lại mọi thứ khác và chỉ trả về điều đó. Cám ơn! – adamJLev
Sử dụng HttpResponse thực sự sẽ chấm dứt lời nhắc về việc xử lý chế độ xem, khi sử dụng bản in hoặc thêm vào ngữ cảnh mẫu có thể giúp bạn xem dữ liệu được chuyển. hơn nữa nếu bạn đã cài đặt thanh công cụ gỡ lỗi, bạn có thể xem tất cả các biến ngữ cảnh được truyền gọn gàng được trình bày trong đó. – phoenix24
Tôi chỉ muốn đưa ra một câu trả lời khác: Đơn giản chỉ cần sử dụng print báo cáo và phục vụ trang web django của bạn với python manage.py runserver
Trong trường hợp này, các câu lệnh print hiển thị trong trình bao của bạn và trang web của bạn tiếp tục hoạt động vì nó sẽ là tiêu chuẩn đồng minh.
Mẹo tuyệt vời, cảm ơn! – adamJLev
Trừ khi bạn bị khóa vào gỡ lỗi thông qua Apache (hoặc bất cứ điều gì), thật khó để đánh bại ngay lập tức chạy máy chủ phát triển và chỉ cần thực hiện print() s. Tôi thường có thể làm một chu kỳ quan sát-chỉnh-tải lại-quan sát trong dưới 20 hoặc 30 giây. –
Chỉ cần nhớ để loại bỏ các báo cáo in khi bạn đang thực hiện - để chúng trong sẽ sụp đổ mod_wsgi! – shacker
Nếu bạn không muốn sụp đổ mod_wsgi trên bản in của làm điều này trong tập tin wsgi bạn
sys.stdout = sys.stderr
in sau đó sẽ được gửi đến error_log
Nó không thực sự chính xác để nói rằng mod_wsgi sẽ 'sụp đổ'. Nó là việc sử dụng 'in' để stdout đó là sai. Mod_wsgi mô-đun đã cố tình cố gắng để làm cho bạn viết các ứng dụng WSGI di động bằng cách gắn cờ những gì bạn đang làm sai. Không ai có vẻ quan tâm mặc dù các ứng dụng WSGI của họ không phải là di động và mod_wsgi đã từ bỏ việc cố gắng làm cho bạn làm điều đúng trong mod_wsgi 3.0. Nói cách khác, điều này là không cần thiết trong mod_wsgi 3.X và sau đó. Đọc 'http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html'. –
Nếu bạn đang sử dụng mod_wsgi bạn có thể nói:
print var
raise SystemExit
Ngoại lệ SystemExit sẽ không thực sự khiến toàn bộ quá trình thoát như bình thường, nhưng chỉ yêu cầu thoát ra, giả sử rằng không có mã nào cao hơn bắt được và tôi gnores.
Đảm bảo bạn đang sử dụng mod_wsgi 3.X. Nếu sử dụng mod_wsgi cũ hơn, bạn sẽ cần phải thay vì nói:
import sys
print >> sys.stderr
raise SystemExit
máy chủ WSGI khác cũng có thể điều trị SystemExit trong một yêu cầu cùng một cách, nói rằng bạn sẽ cần phải thử nghiệm như những gì sẽ xảy ra nếu sử dụng giải pháp lưu trữ khác.
Đối với các thông tin khác về gỡ lỗi các ứng dụng WSGI đọc:
tại sao không sử dụng 'chết $ var;' ở nơi đầu tiên? – knittl
Tôi đã cố gắng rõ ràng nhất có thể trong trường hợp "người trả lời câu hỏi python" tiềm năng không biết rằng 'die == exit' :) – adamJLev