Re: [Python-Dev] annoying dictionary problem, non-existing keys

2008-04-25 Thread Collin Winter
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

2007-04-01 Thread Collin Winter
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

2006-08-18 Thread Collin Winter
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

2006-08-01 Thread Collin Winter
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

2006-05-27 Thread Collin Winter
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

2006-04-27 Thread Collin Winter
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

2006-02-12 Thread Collin Winter
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

2006-02-11 Thread Collin Winter
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

2006-02-11 Thread Collin Winter
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

2006-02-10 Thread Collin Winter
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

2005-09-24 Thread Collin Winter
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

2005-09-23 Thread Collin Winter
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

2005-09-23 Thread Collin Winter
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

2005-09-23 Thread Collin Winter
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

2005-09-23 Thread Collin Winter
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

2005-09-23 Thread Collin Winter
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