[Python-Dev] annoying dictionary problem, non-existing keys
i use dictionaries to hold some config data,
such as:
conf={'key1':'value1','key2':'value2'}
and so on...
when i try to process conf, i have to code every time like:
if conf.has_key('key1'):
if conf['key1']<>'':
other commands
this is very annoying.
in php, i was able to code only like:
if conf['key1']=='someth'
in python, this fails, because, if key1 does not exists, it raises an exception.
MY question:
is there a way to directly get value of an array/tuple/dict item by key,
as in php above, even if key may not exist, i should not check if key exist,
i should only use it, if it does not exist, it may return only empty,
just as in php
i hope you understand my question...
--
İ.Bahattin Vidinli
Elk-Elektronik Müh.
---
iletisim bilgileri (Tercih sirasina gore):
skype: bvidinli (sesli gorusme icin, www.skype.com)
msn: [EMAIL PROTECTED]
yahoo: bvidinli
+90.532.7990607
+90.505.5667711
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] annoying dictionary problem, non-existing keys
Python-dev is for discussion of development of future Python. Use python-list / comp.lang.python / gmane.comp.python.general for usage questions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] annoying dictionary problem, non-existing keys
> this is very annoying. Posting to so many lists is even more annoying. You might not get a single helpful answer just because people are so frustrated by this behavior. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] annoying dictionary problem, non-existing keys
I posted to so many lists because, this issue is related to all lists, this is an idea for python, this is related to development of python... why are you so much defensive ? i think ideas all important for development of python, software i am sory anyway hope will be helpful. 2008/4/24, Terry Reedy <[EMAIL PROTECTED]>: > Python-dev is for discussion of development of future Python. Use > python-list / comp.lang.python / gmane.comp.python.general for usage > questions. > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/bvidinli%40gmail.com > -- İ.Bahattin Vidinli Elk-Elektronik Müh. --- iletisim bilgileri (Tercih sirasina gore): skype: bvidinli (sesli gorusme icin, www.skype.com) msn: [EMAIL PROTECTED] yahoo: bvidinli +90.532.7990607 +90.505.5667711 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BSDDB3
> After that, merging his changes into trunk will be relatively easy and I > think we should give jcea commit access and let him do it and henceforth > use python svn as the official repository for the pybsddb code and > documentation. Ok. Jesus, can you please send me your SSH key? > I do not see this as a daunting task assuming jcea is willing to be > volunteered to do the merge and to handle any py3k merge issues that > come up. Ideally, yes. Jesus, if you are uncertain of how exactly the merging works, don't hesitate to ask. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BSDDB3
> Next week I will (if nothing goes wrong) publish pybsddb > 4.6.4. This release supports distributed transactions and > replication, testsuite is way faster, and rewritten to be > able to launch tests from multiple threads/processes if you > wish, setuptools/pypi support, etc. Great! Once you've settled in with your changes let me know and I'll help with doing the necessary things on the Windows-side to set up the bsddb46.vcproj and switching the build to use that. Trent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BSDDB3
Martin v. Löwis wrote: Ok. Jesus, can you please send me your SSH key? Nice to see that Heaven is security conscious and accepting encrypted prayer nowadays. :-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
[Michael working on cleaning up the unittest module] it seems like most of the good ideas have been captured already. I'll through two more (low priority) ideas out there. 1) Randomized test runner/option that runs tests in a random order (like regrtest.py -r, but for methods) 2) decorator to verify a test method is supposed to fail #2 is useful for getting test cases into the code sooner rather than later. I'm pretty sure I have a patch that implements this (http://bugs.python.org/issue1399935). It didn't fit in well with the old unittest structure, but seems closer to the direction you are headed. One other idea that probably ought not be done just yet: add a way of failing with the test continuing. We use this at work (not in Python though) and when used appropriately, it works quite well. It provides more information about the failure. It looks something like this: def testMethod(self): # setup self.assertTrue(precondition) self.expectTrue(value) self.expectEqual(expected_result, other_value) All the expect methods duplicate the assert methods. Asserts can the test to fail immediately, expects don't fail immediately allowing the test to continue. All the expect failures are collected and printed at the end of the method run. I was a little skeptical about assert vs expect at first, but it has proven useful in the long run. As I said, I don't think this should be done now, maybe later. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
Neal Norwitz wrote: All the expect methods duplicate the assert methods. Asserts can the test to fail immediately, expects don't fail immediately allowing the test to continue. All the expect failures are collected and printed at the end of the method run. I was a little skeptical about assert vs expect at first, but it has proven useful in the long run. As I said, I don't think this should be done now, maybe later. I'd agree these kinds of things can be very useful, particularly for tests which run the same test for multiple inputs - when those tests die on the first set of input values that do the wrong thing, it greatly slows down the test-fix-retest cycle, since you have to go through it multiple times. If the test is written to test all the input values, even if some of them fail, and then report at the end "test failed, here are the (input, expected_ouput, actual_output) that didn't work" it can make tests far more efficient. At the moment I do it manually by collected a list of failed triples, then reporting a test failure at the end if the list isn't empty, but something like "expect" methods would avoid the need to recreate that infrastructure every time I need it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
