Re: [Python-Dev] annoying dictionary problem, non-existing keys
2008/4/24 bvidinli <[EMAIL PROTECTED]>: > 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. Please consult the documentation first: http://docs.python.org/lib/typesmapping.html . You're looking for the get() method. This attribute of PHP is hardly considered a feature, and is not something Python wishes to emulate. Collin Winter > 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/collinw%40gmail.com > -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
On 4/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
[snip several pages of excellent ideas]
>
> The mapping between types and declarators is not static. It can be completely
> customized by the programmer, but for convenience there are some predefined
> mappings for some built-in types:
>
> = ===
> Type Declarator
> = ===
> ``object`` � (REPLACEMENT CHARACTER)
> ``int``ℕ (DOUBLE-STRUCK CAPITAL N)
> ``float`` ℮ (ESTIMATED SYMBOL)
> ``bool`` ✓ (CHECK MARK)
> ``complex``ℂ (DOUBLE-STRUCK CAPITAL C)
> ``str``✎ (LOWER RIGHT PENCIL)
> ``unicode``✒ (BLACK NIB)
> ``tuple`` ⒯ (PARENTHESIZED LATIN SMALL LETTER T)
> ``list`` ♨ (HOT SPRINGS)
> ``dict`` ⧟ (DOUBLE-ENDED MULTIMAP)
> ``set``∅ (EMPTY SET) (*Note:* this is also for full sets)
> ``frozenset`` ☃ (SNOWMAN)
> ``datetime`` ⌚ (WATCH)
> ``function`` ƛ (LATIN SMALL LETTER LAMBDA WITH STROKE)
> ``generator`` ⚛ (ATOM SYMBOL)
> ``Exception`` ⌁ (ELECTRIC ARROW)
> = ===
>
> The declarator for the ``None`` type is a zero-width space.
>
> These characters should be obvious and easy to remember and type for every
> programmer.
>
[snip]
>
> Example
> ===
>
> This is the standard ``os.path.normpath`` function, converted to type
> declaration
> syntax::
>
> def normpathƛ(path✎)✎:
> """Normalize path, eliminating double slashes, etc."""
> if path✎ == '':
> return '.'
> initial_slashes✓ = path✎.startswithƛ('/')✓
> # POSIX allows one or two initial slashes, but treats three or more
> # as single slash.
> if (initial_slashes✓ and
> path✎.startswithƛ('//')✓ and not path✎.startswithƛ('///')✓)✓:
> initial_slashesℕ = 2
> comps♨ = path✎.splitƛ('/')♨
> new_comps♨ = []♨
> for comp✎ in comps♨:
> if comp✎ in ('', '.')⒯:
> continue
> if (comp✎ != '..' or (not initial_slashesℕ and not new_comps♨)✓
> or
> (new_comps♨ and new_comps♨[-1]✎ == '..')✓)✓:
> new_comps♨.appendƛ(comp✎)
> elif new_comps♨:
> new_comps♨.popƛ()✎
> comps♨ = new_comps♨
> path✎ = '/'.join(comps♨)✎
> if initial_slashesℕ:
> path✎ = '/'*initial_slashesℕ + path✎
> return path✎ or '.'
>
> As you can clearly see, the type declarations add expressiveness, while at the
> same time they make the code look much more professional.
My only concern is that this doesn't go far enough. While knowing that
some object is a ⒯ is a good start, it would be so much more helpful
to know that it's a ⒯ of ✎s. I think something like ✎✎✎3⒯ to indicate
a 3-⒯ of ✎s would be nice. This would change the line in the above
from "if comp✎ in ('', '.')⒯:" to "if comp✎ in ('', '.')✎✎2⒯:", which
I think is a nice win in terms of readability, EIBTI and all that.
(Sidebar: I think the PEP should feature a section on how these new
type declarations will cut down on mailing list volume and
documentation size.)
In light of this PEP, PEP 3107's function annotations should be
rejected. All that hippie feel-good crap about "user-defined
annotations" and "open-ended semantics" and "no rules, man" was just
going to get us into trouble. This PEP's more modern conception of
type annotations give the language a power and expressiveness that my
PEP could never hope to match.
This is clearly a move in the right direction. +4 billion.
Collin Winter
--
http://mail.python.org/mailman/listinfo/python-list
Questions on unittest behaviour
While working on a test suite for unittest these past few weeks, I've
run across some behaviours that, while not obviously wrong, don't
strike me as quite right, either. Submitted for your consideration:
1) TestCase.tearDown() is only run if TestCase.setUp() succeeded. It
seems to me that tearDown() should always be run, regardless of any
failures in setUp() or the test method itself.
The case I'm considering is something like this, ie, a multi-part setUp():
> def setUp(self)
> lock_file(testfile) # open_socket(), connect_to_database(), etc
>
> something_that_raises_an_exception()
>
> def tearDown(self):
> if file_is_locked(testfile):
> unlock_file(testfile)
In this pseudo-code example, the file won't be unlocked if some later
operation in setUp() raises an exception. I propose that
TestCase.run() be changed to always run tearDown(), even if setUp()
raise an exception.
I'm undecided if this is a new feature (so it should go in for 2.6) or
a bug fix; I'm leaning toward the latter.
2) The TestLoader.testMethodPrefix attribute currently allows anything
to be assigned to it, including invalid objects and the empty string.
While the former will cause errors to be raised when one of
TestLoader's loadTestsFrom*() methods is called, the empty string will
raise no exception; rather, the loadTestsFrom*() methods will
interpret every possible attribute as being a test method, e.g.,
meaning you get things like assertEqual(), failUnlessEqual(), etc,
when TestLoader.loadTestsFromTestCase() is run.
I propose protecting testMethodPrefix with a property that validates
the assigned value, restricting input to non-empty instances of str. I
see this as a bug fix that should go in before 2.5-final.
3) TestLoader.loadTestsFromTestCase() accepts objects that are not
test cases and will happily look for appropriately-named methods on
any object you give it. This flexibility should be documented, or
proper input validation should be done (a bug fix for 2.5).
4) TestLoader.loadTestsFromName() (and by extension,
loadTestsFromNames(), too) raises an AttributeError if the name is the
empty string because -- as it correctly asserts -- the object does not
contain an attribute named ''. I recommend that this be tested for and
ValueError be raised (bug fix for 2.5).
This of course leads into the question of how much input validation
should be done on these names. Should loadTestsFrom{Name,Names}() make
sure the names are valid attribute names, or is this overkill?
5) When TestLoader.loadTestsFrom{Name,Names}() are given a name that
resolves to a classmethod on a TestCase subclass, the method is not
invoked. From the docs:
> The specifier name is a ``dotted name'' that may resolve either to a module,
> a test
> case class, a TestSuite instance, a test method within a test case class, or a
> callable object which returns a TestCase or TestSuite instance.
It is not documented which of these tests takes priority: is the
classmethod "a test method within a test case class" or is it a
callable? The same issue applies to staticmethods as well.
Once I get answers to these questions, I can finish off the last few
bits of the test suite and have it ready for 2.5-final.
Thanks,
Collin Winter
--
http://mail.python.org/mailman/listinfo/python-list
[ANNOUNCE] functional 0.7.0 released
Hello all, I have released version 0.7.0 of my functional module, a collection of higher-order and functional programming tools for Python. Currently offered are tools for function composition, partial function application, plus filter, flip, foldl, foldr, map, scanl and scanr functions. Two version of the release are available: one is written in pure Python and aims for maximum readability and portability. The other is coded as a C extension module and is focused on raw performance. Where to get it: # functional is available from the Python Package Index at http://cheeseshop.python.org/pypi/functional/ Both source tarballs and Python Eggs are available for both the pure Python and C releases. Eggs are available for Python versions 2.3, 2.4 and 2.5. Release Notes + functional now includes map() and filter() functions. These are roughly equivalent to the Python built-in functions, though without some of the weird/incorrect behaviour of the built-ins. Specifically: functional.map() works like the built-in, except functional.map() 1) always takes a single iterable, and 2) doesn't support the None nonsense that the built-in does. functional.filter() works like the built-in, except functional.filter() 1) iterates over subclasses of str, unicode and tuple correctly, 2) doesn't support the None nonsense that the built-in does, 3) always returns a list, unlike the built-in. + Several reference counting-related bugs have been squashed in the C implementation. + The test suite has been enhanced to do reference count checking after each test, making it much easier to track down future errors in the C implementation. + The C implementation now supports Python 2.3, in addition to 2.4 and 2.5 As always, feedback welcome! Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
[ANNOUNCE]: typecheck 0.3.5 released
Hello all, I have released version 0.3.5 of my typecheck module, a Python module providing run-time typechecking facilities for function parameters and return values, as well as generator yield values. The main workhorses of this module, the functions accepts, returns and yields, are used as function/method decorators. These operate on a function arguments, function return values and generator yield values, respectively. A number of utility classes are provided to assist in building more complex signatures, for example, by creating boolean expressions based on classes and/or types. It is possible to incorporate typechecking facilities into user-defined classes. A mixin class, UnorderedIteratorMixin, is provided to allow easy typechecking of iterators. Numerous examples are provided as to how to integrate your own container classes into typecheck. Where to get it: # typecheck is available from the project's website at http://oakwinter.com/code/typecheck/ and from the Python Package Index at http://cheeseshop.python.org/pypi/typecheck Both source tarballs and Python Eggs for Python versions 2.4 and 2.5 are available. Release Notes This is a bug-fix release: + After fixing an issue with the test suite, typecheck is now compatible with Python 2.5 + Compatibility issues: - Typeclass instances are no longer callable. This means that "Number() is not Number" is True. This was done to fix a bug with typeclasses. + Bug fixes: - Add an __all__ list to typecheck/__init__.py - Instances with __call__ methods can now be used as functions (ie, in conjunction with Function) - Unicode can now be used to specify type variables - Rename all message() methods on the internal _TC_* extensions to error_message() (Python 2.5's exceptions already have message attribute) - Add repr() and str() support to Typeclass instances - Fix a bug related to typecheck_args()'s checking of the number of arguments passed to the typechecked function - Fix SF #1495358; typeclasses can now actually be used. As always, feedback welcome! Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
[ANNOUNCE]: functional 0.6 released
Hello all, I have released version 0.6 of my functional module, a collection of higher-order and functional programming tools for Python. Currently offered are tools for function composition, partial function application, plus flip, foldl, foldr, scanl and scanr functions. Two version of the release are available: one is written in pure Python and aims for maximum readability and portability. The other is coded as a C extension module and is focused on raw performance. Where to get it: # functional is available from the project's website at http://oakwinter.com/code/functional/download/ and from the Python Package Index at http://cheeseshop.python.org/pypi/functional. Both source tarballs and Python Eggs are available for both the pure Python and C releases. Eggs are available for Python versions 2.3, 2.4 and 2.5. Release Notes + flip will now reverse all non-keyword arguments, as opposed to simply reversing the first two as it did in version 0.5 (by popular request). + functional.compose now comes with an optional unpack parameter to make up for the fact that Python functions aren't fully curried. The unpack parameter means that you can now do something like this with compose: >>> f(*g(*arg,**kw)) i.e., automatically unpacking g's return value and passing the result to f. To get this functionality, you'd write something like: >>> compose(f, g, unpack=True)(*args, **kwargs) This was impossible with functional 0.5. + Weakref support has been added to flip and compose objects in the C version. + Sundry performance improvements for the C implementation. As always, feedback welcome! Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
[ANN] svnmock 0.3 released
Hello all, Version 0.3 of `svnmock`, a package for testing Python applications that use Subversion's Python bindings, has been released. `svnmock` emulates the entire suite of Python bindings, allowing developers to ensure that their application is calling the expected API functions with the expected arguments. In addition, `svnmock` provides facilities for simulating error conditions that would otherwise be difficult or impossible to test against. Last but not least, `svnmock` includes support for tracing API calls, allowing for quick debugging without the need to mock up an entire application. `svnmock` is compatible with all releases of Subversion, including the just-released 1.3.0. Where to get it: # functional is available at http://oakwinter.com/code/svnmock/ and from the Python Package Index at http://cheeseshop.python.org/pypi/svnmock Source tarballs are available, as are Python Eggs for Python 2.4 and 2.5. Release Notes The 0.3 release is primarily a refinement release. Certain parts of the package have been made much easier to use for the vast majority of use cases. A full tutorial and reference manual is available at http://oakwinter.com/code/svnmock/. As always, feedback welcome! Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: functional 0.5 released
On 10 Feb 2006 19:57:48 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Collin Winter wrote: > > As always, feedback welcome! > > Any specific reason flip only flip the first 2 arguments rather than > the whole tuple ? > > That is, I would like to see: > > assert(f(a,b,c, d) == flip(f)(d, c, b, a)) Because that's what I'm used to from Haskell and other functional languages : ) I'll see what I can do about having it flip all arguments in the next release. Thanks, Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] functional 0.5 released
On 2/11/06, Neal Becker <[EMAIL PROTECTED]> wrote:
> I just installed from .tar.gz on fedora FC5 x86_64. I ran into 1 small
> problem:
>
[snip]
> Because this distribution was installed --multi-version or --install-dir,
> before you can import modules from this package in an application, you
> will need to 'import pkg_resources' and then use a 'require()' call
> similar to one of these examples, in order to select the desired version:
>
> pkg_resources.require("functional") # latest installed version
> pkg_resources.require("functional==0.5") # this exact version
> pkg_resources.require("functional>=0.5") # this version or higher
>
> Processing dependencies for functional==0.5
>
> What's all this about multi-version? Did I do something wrong?
I've tried installing the package in all sorts of ways and haven't
been able to reproduce this problem. I'm guessing that somewhere in
your setuptools configuration, however, that there's a config file
passing --multi-version or --install-dir without your knowledge. Do
you get this same message when installing other Python packages?
Thanks,
Collin Winter
--
http://mail.python.org/mailman/listinfo/python-list
[ANN] functional 0.5 released
Hello all, I have released version 0.5 of my functional module, a collection of higher-order and functional programming tools for Python. Currently offered are tools for function composition, partial function application, plus flip, foldl, foldr, scanl and scanr functions. Two version of the release are available: one is written in pure Python and aims for maximum readability and portability. The other is coded as a C extension module and is focused on raw performance. Where to get it: # functional is available at http://oakwinter.com/code/functional/ and from the Python Package Index at http://cheeseshop.python.org/pypi/functional. Both source tarballs and Python Eggs are available for both the pure Python and C releases. I'm open to user-contributed RPM, Deb or other packagings. Release Notes The biggest news in this release is the addition of the C implementation. Also, a number of functions were removed, as I had unknowingly duplicated a lot of functionality from the itertools module. As always, feedback welcome! Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: Dynamically adding and removing methods
One caveat, as I recently discovered, to dynamically adding methods is that it doesn't work for __foo__ methods. For example, you can't make an object into an iterator by dynamically assigning bound methods to obj.__iter__ and obj.next. Same thing with __getitem__, __setitem__, etc; adding them directly to the instance doesn't get you a subscriptable object. This is because the interpreter looks at the methods defined by the class, rather than the instance's attributes. Just a word of caution. Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: Single type for __builtins__ in Py3.0
On 9/23/05, Peter Hansen <[EMAIL PROTECTED]> wrote: > My point, which might not have been clear, is that users are *already* > told that they shouldn't ever touch __anything__ without understanding > what it is, which is more general advice than and therefore encompasses > the __builtins__ issue. For this reason I believe the existing advice > is sufficient for everyone except those who would probably also end up > ignoring your above suggestions anyway. I'm not proposing a new rule on the level of "learn about __foo__ before you mess with it"; the delegation structure of that rule is sufficient. I do however want the docs for __builtins__ to explicitly mention a) that you should do your mucking with __builtin__ instead, and b) that __builtins__ is a module when in __main__ and a dict everywhere else; the current documentation makes no mention of either. Come morning I'll submit a patch for the reference manual. > > Maybe > > __builtins__ could be removed entirely from Py3.0, thus bringing > > reality in to sync with policy. > > That's a possibility, though given that it's an implementation detail > there could easily be other implementation details which you would then > be asking to be removed as well because they might confuse someone. If > you really want to avoid having implementation details exposed like > this, you should probably be participating closely in the development > process. ;-) I'm relatively new to the python-dev world, but I intend to do what I can to eliminate blemishes like __builtins__. Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: Single type for __builtins__ in Py3.0
On 9/23/05, Peter Hansen <[EMAIL PROTECTED]> wrote: > User are clearly told in various places that names with leading and > trailing double underscores are *special*, and at least by implication > they are not to be used without a good understanding of what they are. > You certainly shouldn't have found any docs telling you to use > __builtins__ that way. > > http://www.google.ca/search?q=site%3Apython.org+__builtin__ is a pretty > quick way of finding the above docs, and while doing the same search > with __builtins__ admittedly finds lots of mailing list archives where > people have the same misconception as you did, it doesn't take one past > the second page of results before you'll be right back at a post by > Fredrik pointing out the same mistake. :-) The difference between __builtins__ and the other __*__ names is that while the others shouldn't be used without understanding their purpose, the consensus on __builtins__ seems to be that it shouldn't be used at all. Since you mention Fredrik's posts on the subject, I'll quote one for you: http://mail.python.org/pipermail/python-list/2002-June/109090.html """ forget about __builtins__; it's an implementation detail. if you need to explicitly refer to stuff in the built-in namespace, *always* import the __builtin__ module. never use __builtins__ in your code. """ Other posts echo this. To my mind this indicates that, at the very least, users should be explicitly told -- up front, in the official documentation -- that they shouldn't ever touch __builtins__. Maybe __builtins__ could be removed entirely from Py3.0, thus bringing reality in to sync with policy. Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: Single type for __builtins__ in Py3.0
On 9/23/05, Christopher Subich <[EMAIL PROTECTED]> wrote: > How would this change, if made in a minimal way, impact the "provide > alternate globals() and locals() to eval and exec" feature? Altering > __builtins__ is a half-assed way of providing some sort of security, but > it's probably useful in preventing user-supplied code from shooting > itself in the foot without aiming first. In all cases (eval, exec, execfile), the globals parameter must be a dict and the locals can be any mapping object, so the value of the __builtins__ key would just need to be a module (could be created with the "new" module). This is about the same breakage as with any other code using __builtins__. One possibility would be to deprecate the dict-form. This could be done as Tom Anderson suggests, by supporting both __getattr__ and __getitem__, with the latter issuing a deprecation warning for a while. My tests indicate that this is possible, with both module.attr and module['item'] forms available. Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Re: Single type for __builtins__ in Py3.0
On 9/23/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Collin Winter wrote: > > > As it currently stands, the type of the global __builtins__ differs > > depending on whether you're in the __main__ namespace (__builtins__ is > > a module) or not (its a dict). I was recently tripped up by this > > discrepancy, and googling the issue brings up half-a-dozen or so c.l.p > > threads where others have been bitten by this, too. > > __builtins__ is a CPython implementation detail. why not just let it > be an implementation detail, and refrain from using it? it's not that > hard, really. Given, but I fail to see why it can't be a consistent implementation detail. After my own encounter with __builtins__, I now know that I should use __builtin__ instead. However, the docs never mention this. The only way you'd know that __builtin__ is preferred is by searching the list archives, something you're not likely to do unless you're already having a problem. If it's decided to leave things they way they are, at the very least the docs should be amended to indicate that users shouldn't be touching __builtins__. If anyone has a suggestion as to where this kind of thing might best fit (tutorial, library reference, language reference?), I'd be happy to write a patch for the docs. Collin Winter -- http://mail.python.org/mailman/listinfo/python-list
Single type for __builtins__ in Py3.0
Hallo all, As it currently stands, the type of the global __builtins__ differs depending on whether you're in the __main__ namespace (__builtins__ is a module) or not (its a dict). I was recently tripped up by this discrepancy, and googling the issue brings up half-a-dozen or so c.l.p threads where others have been bitten by this, too. I'd like to propose that in Py3.0 (if not earlier), __builtins__ will be the same type regardless of which namespace you're in. Tim Peters has said [1] that the reason __builtins__ in __main__ is a module so that "the curious don't get flooded with output when doing vars() at the prompt". Based on this, I propose that __builtins__ be a module (really, an alias for the __builtin__ module as it is now) in all namespaces. If possible, I'd like to see this go in before 3.0. The reference manual currently states [2] that __builtins__ can be either a dict or a module, so changing it to always be a module would still be in keeping with this. However, I realise that there's probably code out there that hasn't been written to deal with both types, so this would result in some minor breakage (though it would be easily fixable). If this gets a good response, I'll kick it up to python-dev. Thanks, Collin Winter [1] http://mail.python.org/pipermail/python-list/2002-May/103613.html [2] http://www.python.org/doc/2.4.1/ref/naming.html -- http://mail.python.org/mailman/listinfo/python-list
