Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17604 > unrolled thread

Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.

Back to article view | Back to comp.lang.python

Contents

  Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Nathan Rice <nathan.alexander.rice@gmail.com> - 2011-12-20 14:45 -0500
    Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-20 20:29 +0000
      Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Nathan Rice <nathan.alexander.rice@gmail.com> - 2011-12-20 15:45 -0500
        Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-20 21:00 +0000
          Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Paul Rubin <no.email@nospam.invalid> - 2011-12-20 13:08 -0800
            Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-21 00:12 +0000
          Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Nathan Rice <nathan.alexander.rice@gmail.com> - 2011-12-20 16:20 -0500
            Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-21 00:28 +0000
              Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Ethan Furman <ethan@stoneleaf.us> - 2011-12-21 09:22 -0800
      Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. MRAB <python@mrabarnett.plus.com> - 2011-12-20 20:47 +0000
      Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python. Chris Angelico <rosuav@gmail.com> - 2011-12-21 08:10 +1100

#17604 — Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.

Elementwise provides a proxy object for iterables which supports
chained method calls, as well as elementwise expressions and some
built-in functions.

Example:

    class ExampleList(ElementwiseProxyMixin, list):
        def __new__(cls, iterable):
            return list.__new__(cls, iterable)
    foo = ExampleList([1, 2, 3, 4])

    # You could also do: efoo = ElementwiseProxy(foo)
    efoo = foo.each

    assert list(efoo.bit_length()) == [1, 2, 2, 3]
    print "bit length: ", list(efoo.bit_length())
    assert list(efoo + 1) == [2, 3, 4, 5]
    print "with addition of 1: ", list(efoo + 1)
    assert list(efoo * 2) == [2, 4, 6, 8]
    print "with multiplication by 2: ", list(efoo * 2)
    assert list(efoo == 2) == [False, True, False, False]
    print "testing equality: ", efoo == 2
    assert list((efoo + 1) * 2 + 3) == [7, 9, 11, 13]
    print "chaining addition and multiplication: ", (efoo + 1) * 2 + 3

Each ElementwiseProxy also has a "parent" attribute so you can
backtrack in the chain as needed rather than store each intermediate
value, if you think you might need them.

There are still some issues with proper support of things like bool()
and int(), which refuse to return things that are not of the correct
type.

Get it:

    PyPi: http://pypi.python.org/pypi/elementwise/0.111220
    GitHub: https://github.com/nathan-rice/Elementwise

This was developed as a proof of concept for expanding the role of
element-wise syntax in python, and to that end I welcome comments.

Nathan Rice

[toc] | [next] | [standalone]

#17610

On Tue, 20 Dec 2011 14:45:06 -0500, Nathan Rice wrote:

>     PyPi: http://pypi.python.org/pypi/elementwise/0.111220

Version 0.111220? What do you do, bump the version number after every 
keystroke?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17612

If you take a moment and examine the version number, you will notice
that it is a date code.  In my opinion that is far more informative
than an arbitrary number.  I use the major version number to
signify... Wait for it... Major changes :)

[toc] | [prev] | [next] | [standalone]

#17618

On Tue, 20 Dec 2011 15:45:07 -0500, Nathan Rice wrote:

> If you take a moment and examine the version number, you will notice
> that it is a date code.

Not any date code I'm familiar with. 0.111220 doesn't look anything like 
a date to me.

Possibly if the last release was two thousand years ago. I'd rather stick 
to actively maintained software, if it's all the same with you.


> In my opinion that is far more informative than
> an arbitrary number.  I use the major version number to signify... Wait
> for it... Major changes :)

Well, that's one opinion. Another opinion is that nobody cares what 
specific day you release a new version, and that versions 0.191231 and 
0.200101 probably aren't that big a difference.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17620

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> Not any date code I'm familiar with. 0.111220 doesn't look anything like 
> a date to me.

0 is the major version number.  111220 (the minor version number) is the
date code, 2011-12-20 being today.

[toc] | [prev] | [next] | [standalone]

#17629

On Tue, 20 Dec 2011 13:08:09 -0800, Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> Not any date code I'm familiar with. 0.111220 doesn't look anything
>> like a date to me.
> 
> 0 is the major version number.  111220 (the minor version number) is the
> date code, 2011-12-20 being today.

Not here it isn't. It is yesterday.


Writing-from-Down-Under-ly y'rs,

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17622

On Tue, Dec 20, 2011 at 4:00 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 20 Dec 2011 15:45:07 -0500, Nathan Rice wrote:
>
>> If you take a moment and examine the version number, you will notice
>> that it is a date code.
>
> Not any date code I'm familiar with. 0.111220 doesn't look anything like
> a date to me.
>
> Possibly if the last release was two thousand years ago. I'd rather stick
> to actively maintained software, if it's all the same with you.

Date code != date.

>> In my opinion that is far more informative than
>> an arbitrary number.  I use the major version number to signify... Wait
>> for it... Major changes :)
>
> Well, that's one opinion. Another opinion is that nobody cares what
> specific day you release a new version, and that versions 0.191231 and
> 0.200101 probably aren't that big a difference.

Nobody cares about version numbers in general, except as a way to
fulfill dependencies.  By using a date code, your versions are
guaranteed to sort in release order (which is nice, say if someone was
to download your software via FTP), you can tell what release has what
ticket fixes in an issue tracker, stuff like that.  It also gives me
an easy way to be nostalgic about releases....

As for the extra "20" that I exclude, if I haven't updated the major
version number by the time 2020 rolls around I deserve any trouble it
causes :)

[toc] | [prev] | [next] | [standalone]

#17631

On Tue, 20 Dec 2011 16:20:37 -0500, Nathan Rice wrote:

>> Well, that's one opinion. Another opinion is that nobody cares what
>> specific day you release a new version, and that versions 0.191231 and
>> 0.200101 probably aren't that big a difference.
> 
> Nobody cares about version numbers in general, except as a way to
> fulfill dependencies.  By using a date code, your versions are
> guaranteed to sort in release order (which is nice, say if someone was
> to download your software via FTP), you can tell what release has what
> ticket fixes in an issue tracker, stuff like that.

*blink*

It must be nice to have software with so few bugs that you can remember 
the date you fixed each and every one just from the ticket number.


I don't actually care what version numbering scheme you use. I had just 
never come across using part of a date as the version number before, and 
I don't think that it is any more recognisable or sensible than any other 
arbitrary numbering scheme. And it is arbitrary: the fact that you 
happened to make a release on Tuesday rather than Wednesday doesn't have 
any meaning (particularly if you're a night owl who is coding at 
midnight) and yet you'll assign a different version number to it. To my 
mind, the version number should encode (in some sense) the feature set, 
not the date you release it.

It also has the serious disadvantage that you're limited to a single 
release per day, unless you add an extra field to the version string.

But whatever floats your boat. I'm just glad that you've put your money 
where your mouth is, and released the package, instead of demanding 
others do the work. Thank you.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17682

Steven D'Aprano wrote:
> I'm just glad that you've put your money 
> where your mouth is, and released the package, instead of demanding 
> others do the work. Thank you.

+1000!

~Ethan~

[toc] | [prev] | [next] | [standalone]

#17613

On 20/12/2011 20:29, Steven D'Aprano wrote:
> On Tue, 20 Dec 2011 14:45:06 -0500, Nathan Rice wrote:
>
>>      PyPi: http://pypi.python.org/pypi/elementwise/0.111220
>
> Version 0.111220? What do you do, bump the version number after every
> keystroke?
>
It looks like it's based on the date. I do something similar with the
regex module, except that _my_ version number is Y2K compliant. :-)

[toc] | [prev] | [next] | [standalone]

#17621

On Wed, Dec 21, 2011 at 7:47 AM, MRAB <python@mrabarnett.plus.com> wrote:
> It looks like it's based on the date. I do something similar with the
> regex module, except that _my_ version number is Y2K compliant. :-)

The eight-digit date is a recognized entity. The truncated six-digit
form, much less so.

But either is better known than what PPWizard uses, which involves the
day-of-year...

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web