[issue10190] Can argparse._AttributeHolder._get_kwargs become a public API?
New submission from Dariusz Suchojad : Hello, I was wondering if it were possible for the argparse._AttributeHolder._get_kwargs to become a part of the public API. Using this method is a very convenient way to get a hold of the arguments provided by the user and it would be shame to keep it private, I for one use it in several places even though I clearly know the name starts with an underscore, it's just that reimplementing it in my code seems counter-productive, would be very nice if '_get_kwargs' became 'get_kwargs' in some future release. Thanks for considering it! -- assignee: d...@python components: Documentation, Library (Lib) messages: 119539 nosy: bethard, d...@python, dsuch priority: normal severity: normal status: open title: Can argparse._AttributeHolder._get_kwargs become a public API? type: feature request ___ Python tracker <http://bugs.python.org/issue10190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10190] Can argparse._AttributeHolder._get_kwargs become a public API?
Dariusz Suchojad added the comment: I find that _AttributeHolder is a handy way for passing the command line options around the application. What is lacks though is a documented API for actually fetching the attributes in batches, like .items() or something similar that could be used for iterating over all command line arguments. That's why I thought '_get_kwargs' would be a good candidate particularly because it does exactly what I need in my code, returns a sorted list of key/value parameters. But I'm not really saying that it must be '_get_kwargs', could as well be _AttributeHolder's __dict__ attribute as long as the docs say that it's a part of the public API so that I'm sure I'm not using something that may silently break between releases. -- ___ Python tracker <http://bugs.python.org/issue10190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1737] Windows installer issue (ObjectBrowser.py)
New submission from Dariusz Suchojad: Hello, for some reasons I cannot install Python 2.5.1 using the default MSI package which may be found here http://www.python.org/ftp/python/2.5.1/python-2.5.1.msi. This only happens on two of my PC's at work but I cannot reproduce it at home. The only difference I could find between those Windows is that the PC's at work are connected to Active Directory domain whereas my home machine isn't. I tried to install Python as a domain user and also as a local administrator but every time I encountered the very same screen (see attached file objectbrowser.png) and then the installation process rollbacks. I'd like to investigate it further but I have no slightest idea where to start. Do you perhaps have any suggestions? It's all Windows XP SP2. -- components: Installation, Windows files: objectbrowser.png messages: 59234 nosy: dsuch severity: normal status: open title: Windows installer issue (ObjectBrowser.py) type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9060/objectbrowser.png __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1737> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1737] Windows installer issue (ObjectBrowser.py)
Dariusz Suchojad added the comment: Done. Attached in python.zip. I've also noticed something strange here. http://python.org/download/releases/2.5.1/ says the MD5 sum should be a1d1a9c07bc4c78bd8fa05dd3efec87f but the MD5 client I'm using (http://www.pc-tools.net/win32/md5sums/) tells me the http://python.org/ftp/python/2.5.1/python-2.5.1.msi file's checksum is D:\tmp\python_install>md5 python-2.5.1.msi MD5sums 1.2 freeware for Win9x/ME/NT/2000/XP+ Copyright (C) 2001-2005 Jem Berkes - http://www.pc-tools.net/ Type md5 -h for help [Path] / filename MD5 sum --- [D:\tmp\python_install\] python-2.5.1.msi bd4780277a4bdfcd693593379e1b383c What does it mean? Is it my client fault? Added file: http://bugs.python.org/file9095/python.zip __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1737> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1737] Windows installer issue (ObjectBrowser.py)
Dariusz Suchojad added the comment: Hmm, on a home PC the checksum's correct, it's a1d1a9c07bc4c78bd8fa05dd3efec87f. Assuming something is wrong with my download at work, is it possible for an MSI package to start the installation even when package is corrupted? Anyway, tomorrow I'll try to install the MSI I downloaded at home. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1737> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1737] Windows installer issue (ObjectBrowser.py)
Dariusz Suchojad added the comment: I think we can close the issue (although I seem not be able to do that). The installer works just fine now I've downloaded it using another browser. For future reference - the former one was Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071030 SeaMonkey/1.1.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1737> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11129] logging: allow multiple entries in qualname config
Dariusz Suchojad added the comment: Hello friends, @vinay.sajip - the use case for this feature is actually something I come across fairly often. In an application I have dozens and hundreds of logger instances. However, they all fall into one of several loggers. Most of the instances are obtained through a module-wide logger = getLogger(__name__). Now I have a feature in the application split over a couple of modules, in different namespaces: zato.common.scheduler zato.server.scheduler They are independent yet related and it would be most convenient if I could list both in qualname - they really should share the logging configuration, at no point they should have separate handlers, logging formats, anything. As an aside, regarding dict configuration - I know you made the comment in 2011 so it may not represent your current opinion but please keep in mind that logging config is something that on production is updated by administrators, i.e. whatever the latest trends in software development are, they aren't necessarily programmers. People I work with have no problems with customizing ini-like files but Python dicts are an entirely different story, they are simply afraid of doing it - a missing apostrophe may mean a couple of hours wasted, for instance. -- nosy: +dsuch ___ Python tracker <http://bugs.python.org/issue11129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19095] Document SSLSocket.getpeercert always returns None without do_handshake
New submission from Dariusz Suchojad: Hello, I'd like to suggest adding a simple note to SSLSocket.getpeercert stating that it will always return None if do_handshake has never been called. This is not the default behaviour, by default SSLSocket.__init__'s do_handshake_on_connect is True so .getpeercert nicely returns a cert (assuming the usual caveats - the other side offers a certificate and cert_reqs is not CERT_NONE). However, I've just been debugging a someone else's server and I spent some time figuring out why client certificates weren't available - turned out this was because do_handshake was never called (PySSL_SSLdo_handshake in _ssl.c). Adding a single-sentence line will certainly be very helpful. Many thanks! -- assignee: docs@python components: Documentation messages: 198425 nosy: docs@python, dsuch priority: normal severity: normal status: open title: Document SSLSocket.getpeercert always returns None without do_handshake type: enhancement ___ Python tracker <http://bugs.python.org/issue19095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19095] Document SSLSocket.getpeercert always returns None without do_handshake
Dariusz Suchojad added the comment: > None isn't helpful as it could mean other things. This is another story but yes, it's true. API-wise, None should be returned in one situation only - we're on server side, ca_certs is non-CERT_NONE, do_handshake has been called yet there is no client certificate. And no other checks should be applied. But the current behavior of returning None is documented and people depend on it so straightening it out would break backward compatibility - it's up to you to decide. I wouldn't mind it personally. But as far as this ticket goes - I'm on 2.7 and it's set in stone so for 2.7 - can you please change copy only? If you decide that for 3.x an exception will be raised then such a caveat would be included in 2.7 docs as well. Thanks again. -- ___ Python tracker <http://bugs.python.org/issue19095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19095] Document SSLSocket.getpeercert always returns None without do_handshake
Dariusz Suchojad added the comment: > I'm not sure people depend on getpeercert() returning None before the > handshake is done, or perhaps by accident? Ah, no, I meant that people may depend on the documented behaviour of .getpeercert's returning an empty dict (which I mixed up with returning None) if the certificate was not validated. That this dictionary's contents depends on the validation is a bit quirky but it's documented so changing that one would surely break existing code. -- ___ Python tracker <http://bugs.python.org/issue19095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6992] PEP 314 inconsistency (authors/author/maintainer)
Dariusz Suchojad added the comment: Hello, funny the bug report should surface in the very same time I was looking for a way to put 2 authors in the 'author' field :-) [Antoine Pitrou (pitrou)] > It is still unknown what use case the new "author" scheme would solve > that the old one doesn't I believe I have such a use case. I'm in the middle of taking over a Python package and I would like to give credits to the original author who passed the development over to me. You see, *he is* the author of 95% of the code, it seems unfair to replace his name with my own. I thought I could simply use a list of authors but the 'author' field hasn't been designed for it. [Antoine Pitrou (pitrou)] > (does someone want the "author"field to be machine parsable? > for what purpose?), I'm just a regular user and when I see a field described as a 'meta' one then I'm actually not wondering how any future tools will take advantage of it. It being a 'meta' I understand it's mostly meant to be interpreted by machines which, funnily enough, seems to be just to the contrary of what you say. Of course one can put anything they wish into 'author', it could even be CSV or XML but that's not the point, the point is that some things simply have two and more authors and inserting the mailing list isn't exactly the same. Sure, I can simply put it all in an AUTHORS file but again it's not the same, what would be the 'author' field for then? If someone were to ask me then I'd say there should only be the 'author' and 'contributor' fields which both have a clear meaning in open-source world, accepting both a string and a list/tuple in format of 'Foo Bar ' which makes for easy parsing and other fields discussed here should be deprecated. No one likes type checking but at least it would provide backwards-compat for the most widely used field. Just my 2c. author = 'Foo Bar ' author = ['Foo Bar ', 'Baz Frobble '] But hey, I still very much like distutils :-) and I understand all the backwards-compatibility concerns, but as a user I can clearly see a need for /some/ way to specify more than one author without having to wonder what will any not-yet-written tool do with this or any other meta field. -- nosy: +dsuch ___ Python tracker <http://bugs.python.org/issue6992> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
