date:20130503

Le Fri, 3 May 2013 09:14:22 +1000,
Nick Coghlan  a écrit :
> >
> > The other issue is your proposal to have a class-based convenience
> > syntax
> akin to (correct me if I got this wrong):
> >
> > class Animal(Enum):
> >   __values__ = 'cat dog'
> 
> I would suggest moving the field names into the class header for a
> class based convenience API:
> 
> class Animal(Enum, members='cat dog'): pass

This looks good to me (assuming some people don't like the
special attribute scheme).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Le Thu, 2 May 2013 14:57:35 -0700,
Eli Bendersky  a écrit :
> 
> class Animal(Enum):
>   __values__ = 'cat dog'
> 
> This is obviously a matter of preference (and hence bikeshedding),
> but this still looks better to me:
> 
> Animal = Enum('Animal', 'cat dog')
> 
> It has two advantages:
> 
> 1. Shorter

You're gaining one line of code. I suppose it's significant if you
write ten enums a day, otherwise... ;-)

> 2. Parallels namedtuple, which is by now a well known and widely used
> construct

namedtuple is the exception, not the rule. I don't know of another
popular type which follows a similar scheme. On the other hand,
well-known ORMs (SQLAlchemy, Django ORM) use a class-based syntax
despite their declarative nature and the fact that they allow you to
set "meta" options (e.g. the name of the reflected table).

As an egoistical data point, I always subclass namedtuples, because I
minimally want to add a docstring, and sometimes I also want to add
behaviour (e.g. alternate constructors, serialization). Which means
namedtuple's declarative conciseness is generally lost for me :-)

Note that besides ORMs, the proposed __values__ has built-in
precedent with __slots__.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Steven D'Aprano


On 03/05/13 18:42, Antoine Pitrou wrote:

Le Fri, 3 May 2013 09:14:22 +1000,
Nick Coghlan  a écrit :



I would suggest moving the field names into the class header for a
class based convenience API:

class Animal(Enum, members='cat dog'): pass


This looks good to me (assuming some people don't like the
special attribute scheme).


The problem is that this is not an expression, it is a statement. The advantage 
of the convenience function is not just that it is shorter, but that it is an 
expression.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Le Fri, 03 May 2013 19:40:21 +1000,
Steven D'Aprano  a écrit :
> On 03/05/13 18:42, Antoine Pitrou wrote:
> > Le Fri, 3 May 2013 09:14:22 +1000,
> > Nick Coghlan  a écrit :
> 
> >> I would suggest moving the field names into the class header for a
> >> class based convenience API:
> >>
> >> class Animal(Enum, members='cat dog'): pass
> >
> > This looks good to me (assuming some people don't like the
> > special attribute scheme).
> 
> The problem is that this is not an expression, it is a statement. The
> advantage of the convenience function is not just that it is shorter,
> but that it is an expression.

What does that change exactly?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Stefan Behnel

Ethan Furman, 02.05.2013 21:07:
> In order for the Enum convenience function to be pickleable, we have this
> line of code in the metaclass:
> 
> enum_class.__module__ = sys._getframe(1).f_globals['__name__']

What a hack. And fragile, too.


> This works fine for Cpython, but what about the others?

This doesn't work when used from Cython compiled code due to the lack of
frames. They are only created for exception tracebacks and not for normal
code by default (just for profiling, coverage etc.). My guess is that
no-one noticed the problem for namedtuples so far because using them is
still uncommon enough in general, let alone pickling them, and the module
name hack only leads to an error when someone tries to pickle such an object.

I think that this will be more of a problem for enums than for namedtuples,
because enums are more likely to appear in data structures that people want
to pickle.

The most simple work-around seems to be this, once you know about it:

"""
ttuple = namedtuple('ttuple', 'a b c')
ttuple.__module__ = __name__   # enable pickle support
"""

Not any worse than the hack above, IMHO, but at least guaranteed to work.

For enums, a regular class based declaration can easily avoid this hack, so
my vote is for getting rid of the "convenience" API before it starts doing
any harm. Or document it explicitly as generating unpicklable objects, as
Antoine suggests.

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-05-03 Thread Paul Moore

On 2 April 2013 01:47, Daniel Holth  wrote:

> This PEP proposes to fix these problems by re-publicising the feature,
> defining the .pyz and .pyzw extensions as “Python ZIP Applications”
> and “Windowed Python ZIP Applications”, and providing some simple
> tooling to manage the format.
>

There is a bug in Windows Powershell, which is apparently due to a bug in
the underlying FindExecutable API, that can fail to recognise extensions
which are longer than 3 characters properly.

Rather than risk obscure bugs, I would suggest restricting the extensions
to 3 characters. For the “Windowed Python ZIP Applications” case, could we
use .pzw as the extension instead of .pyzw?

Please don't shoot the messenger here - I'm not going to try to defend such
a stupid Windows bug, but better to be safe in my view. Flames about
Windows to /dev/null...

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 3 May 2013 20:40, "Paul Moore"  wrote:
>
> On 2 April 2013 01:47, Daniel Holth  wrote:
>>
>> This PEP proposes to fix these problems by re-publicising the feature,
>> defining the .pyz and .pyzw extensions as “Python ZIP Applications”
>> and “Windowed Python ZIP Applications”, and providing some simple
>> tooling to manage the format.
>
>
> There is a bug in Windows Powershell, which is apparently due to a bug in
the underlying FindExecutable API, that can fail to recognise extensions
which are longer than 3 characters properly.
>
> Rather than risk obscure bugs, I would suggest restricting the extensions
to 3 characters. For the “Windowed Python ZIP Applications” case, could we
use .pzw as the extension instead of .pyzw?
>
> Please don't shoot the messenger here - I'm not going to try to defend
such a stupid Windows bug, but better to be safe in my view. Flames about
Windows to /dev/null...

I'm OK with the shortened extension.

Cheers,
Nick.

>
> Paul.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?


Barry Warsaw wrote:

I still don't get it why this is an issue though, or at least why this is
different than any other getattr on any other class,


It's not a problem that getattr() has this behaviour.
What I'm questioning is the idea that getattr() should
be the only provided way of doing a name->enum lookup,
because that will require everyone to do extra checks
to ensure safety.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-03 Thread Eli Bendersky

On Fri, May 3, 2013 at 6:34 AM, Greg Ewing wrote:

> Barry Warsaw wrote:
>
>> I still don't get it why this is an issue though, or at least why this is
>> different than any other getattr on any other class,
>>
>
> It's not a problem that getattr() has this behaviour.
> What I'm questioning is the idea that getattr() should
> be the only provided way of doing a name->enum lookup,
> because that will require everyone to do extra checks
> to ensure safety.
>

I'm just curious what it is about enums that sets everyone on a "let's make
things safer" path. Python is about duck typing, it's absolutely "unsafe"
in the static typing sense, in the most fundamental ways imaginable. When
programmatically invoking a method on a class (say some sort of RPC), we
don't check that the class is of the correct type. We invoke a method, and
if it quacks, that's a good enough duck. If it was actually the wrong
class, something will break later. EAFP Is a central Python tenet, whether
we like it or not. If one looks for static guarantees, Python surely
shouldn't be the preferred language, no?

And concretely, how is this case different from any programmatic attribute
access in Python objects? You can pass dunders to getattr() and it probably
wasn't what you meant, but Python does not do this type checking for you.
Why is an Enum different than any other class?

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-03 Thread Guido van Rossum

On Fri, May 3, 2013 at 7:14 AM, Eli Bendersky  wrote:
> I'm just curious what it is about enums that sets everyone on a "let's make
> things safer" path. Python is about duck typing, it's absolutely "unsafe" in
> the static typing sense, in the most fundamental ways imaginable. When
> programmatically invoking a method on a class (say some sort of RPC), we
> don't check that the class is of the correct type. We invoke a method, and
> if it quacks, that's a good enough duck. If it was actually the wrong class,
> something will break later. EAFP Is a central Python tenet, whether we like
> it or not. If one looks for static guarantees, Python surely shouldn't be
> the preferred language, no?
>
> And concretely, how is this case different from any programmatic attribute
> access in Python objects? You can pass dunders to getattr() and it probably
> wasn't what you meant, but Python does not do this type checking for you.
> Why is an Enum different than any other class?

Let's make that a topic for a separate, more philosophical thread, python-ideas.

Back to this particular issue, I haven't seen code in the style that
Greg proposes in decades, and I don't think it is an important enough
use case to support more directly than through getattr() +
isinstance().

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2013-05-03 Thread Python tracker


ACTIVITY SUMMARY (2013-04-26 - 2013-05-03)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open3953 ( +4)
  closed 25714 (+40)
  total  29667 (+44)

Open issues with patches: 1773 


Issues opened (27)
==

#17585: IDLE - regression with exit() and quit()
http://bugs.python.org/issue17585  reopened by serhiy.storchaka

#17825: Indentation.offset and SyntaxError.offset mismatch
http://bugs.python.org/issue17825  reopened by flox

#17852: Built-in module _io can loose data from buffered files at exit
http://bugs.python.org/issue17852  opened by arigo

#17854: symmetric difference operation applicable to more than two set
http://bugs.python.org/issue17854  opened by Amit.Saha

#17855: Implement introspection of logger hierarchy
http://bugs.python.org/issue17855  opened by vinay.sajip

#17857: sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4
http://bugs.python.org/issue17857  opened by lemburg

#17858: Different documentation for identical methods
http://bugs.python.org/issue17858  opened by amysyk

#17859: improve error message for saving ints to file
http://bugs.python.org/issue17859  opened by techtonik

#17860: subprocess docs lack info how to use output result
http://bugs.python.org/issue17860  opened by techtonik

#17861: put opcode information in one place
http://bugs.python.org/issue17861  opened by benjamin.peterson

#17862: itertools.chunks(iterable, size, fill=None)
http://bugs.python.org/issue17862  opened by techtonik

#17868: pprint long non-printable bytes as hexdump
http://bugs.python.org/issue17868  opened by serhiy.storchaka

#17870: Python does not provide PyLong_FromIntMax_t() or PyLong_FromUi
http://bugs.python.org/issue17870  opened by Devin Jeanpierre

#17871: Wrong signature of TextTestRunner's init function
http://bugs.python.org/issue17871  opened by piotr.dobrogost

#17872: Crash in marshal.load() with bad reader
http://bugs.python.org/issue17872  opened by serhiy.storchaka

#17873: _ctypes/libffi missing bits for aarch64 support
http://bugs.python.org/issue17873  opened by schwab

#17874: ProcessPoolExecutor in interactive shell doesn't work in Windo
http://bugs.python.org/issue17874  opened by Decade

#17877: Skip test_variable_tzname when the zoneinfo database is missin
http://bugs.python.org/issue17877  opened by ezio.melotti

#17878: There is no way to get a list of available codecs
http://bugs.python.org/issue17878  opened by pmoore

#17882: test_objecttypes fails for 3.2.4 on CentOS 6
http://bugs.python.org/issue17882  opened by bharper

#17883: Fix buildbot testing of Tkinter
http://bugs.python.org/issue17883  opened by zach.ware

#17884: Try to reuse stdint.h types like int32_t
http://bugs.python.org/issue17884  opened by haypo

#17887: docs: summary page - generator vs iterator vs iterable
http://bugs.python.org/issue17887  opened by techtonik

#17888: docs: more information on documentation team
http://bugs.python.org/issue17888  opened by techtonik

#17890: argparse: mutually exclusive groups full of suppressed args ca
http://bugs.python.org/issue17890  opened by gholms

#17893: Refactor reduce protocol implementation
http://bugs.python.org/issue17893  opened by alexandre.vassalotti

#17894: Edits to descriptor howto
http://bugs.python.org/issue17894  opened by nedbat



Most recent 15 issues with no replies (15)
==

#17894: Edits to descriptor howto
http://bugs.python.org/issue17894

#17893: Refactor reduce protocol implementation
http://bugs.python.org/issue17893

#17887: docs: summary page - generator vs iterator vs iterable
http://bugs.python.org/issue17887

#17883: Fix buildbot testing of Tkinter
http://bugs.python.org/issue17883

#17882: test_objecttypes fails for 3.2.4 on CentOS 6
http://bugs.python.org/issue17882

#17877: Skip test_variable_tzname when the zoneinfo database is missin
http://bugs.python.org/issue17877

#17873: _ctypes/libffi missing bits for aarch64 support
http://bugs.python.org/issue17873

#17872: Crash in marshal.load() with bad reader
http://bugs.python.org/issue17872

#17862: itertools.chunks(iterable, size, fill=None)
http://bugs.python.org/issue17862

#17848: issue about compile with clang and build a shared lib
http://bugs.python.org/issue17848

#17844: Add link to alternatives for bytes-to-bytes codecs
http://bugs.python.org/issue17844

#17840: base64_codec uses assert for runtime validity checks
http://bugs.python.org/issue17840

#17829: csv.Sniffer.snif doesn't set up the dialect properly for a csv
http://bugs.python.org/issue17829

#17824: pty.spawn handles errors improperly
http://bugs.python.org/issue17824

#17799: settrace docs are wrong about "c_call" events
http://bugs.python.org/issue17799



Most recent 15 issues waiting for review (15)
=

#17894: Edits to descriptor howto
http://bugs.python.

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Barry Warsaw

On May 03, 2013, at 07:40 PM, Steven D'Aprano wrote:

>The problem is that this is not an expression, it is a statement. The
>advantage of the convenience function is not just that it is shorter, but
>that it is an expression.

Exactly right, but let's stop calling it the "convenience API" and instead
call it the "functional API".  I probably started the perpetuation of this
problem; let's update the PEP.

BTW, I made a suggestion elsewhere that the first argument could accept, but
not require dotted names in the first argument.  If provided, rsplit the
string and use the prefix as __module__.  If not given, fallback to the
_getframe() hack for those implementations where it's available.

The same could probably be done to namedtuples.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Guido van Rossum

On Fri, May 3, 2013 at 9:08 AM, Barry Warsaw  wrote:
> On May 03, 2013, at 07:40 PM, Steven D'Aprano wrote:
>
>>The problem is that this is not an expression, it is a statement. The
>>advantage of the convenience function is not just that it is shorter, but
>>that it is an expression.
>
> Exactly right, but let's stop calling it the "convenience API" and instead
> call it the "functional API".  I probably started the perpetuation of this
> problem; let's update the PEP.
>
> BTW, I made a suggestion elsewhere that the first argument could accept, but
> not require dotted names in the first argument.  If provided, rsplit the
> string and use the prefix as __module__.  If not given, fallback to the
> _getframe() hack for those implementations where it's available.
>
> The same could probably be done to namedtuples.

All sounds good to me.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Piotr Duda

2013/5/3 Barry Warsaw :
> On May 03, 2013, at 07:40 PM, Steven D'Aprano wrote:
>
>>The problem is that this is not an expression, it is a statement. The
>>advantage of the convenience function is not just that it is shorter, but
>>that it is an expression.
>
> Exactly right, but let's stop calling it the "convenience API" and instead
> call it the "functional API".  I probably started the perpetuation of this
> problem; let's update the PEP.
>
> BTW, I made a suggestion elsewhere that the first argument could accept, but
> not require dotted names in the first argument.  If provided, rsplit the
> string and use the prefix as __module__.  If not given, fallback to the
> _getframe() hack for those implementations where it's available.

What about adding simple syntax that allows get rid of those ugly
hacks, something like:

def name = expression

which would be rough equivalent for:

name = expression
name.__name__ = 'name'
name.__module__ = __name__

--
闇に隠れた黒い力
弱い心を操る
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Georg Brandl

Am 03.05.2013 11:40, schrieb Steven D'Aprano:
> On 03/05/13 18:42, Antoine Pitrou wrote:
>> Le Fri, 3 May 2013 09:14:22 +1000, Nick Coghlan  a
>> écrit :
> 
>>> I would suggest moving the field names into the class header for a class
>>> based convenience API:
>>> 
>>> class Animal(Enum, members='cat dog'): pass
>> 
>> This looks good to me (assuming some people don't like the special
>> attribute scheme).
> 
> The problem is that this is not an expression, it is a statement. The
> advantage of the convenience function is not just that it is shorter, but
> that it is an expression.

But using that expression in any form other than

NAME = Enum('NAME', ...)

will again result in an unpicklable enum, which was the point of this thread.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

2013-05-03 Thread Terry Jan Reedy


On 5/3/2013 12:08 PM, Barry Warsaw wrote:


Exactly right, but let's stop calling it the "convenience API" and instead
call it the "functional API".  I probably started the perpetuation of this
problem; let's update the PEP.


Please do. To me, a 'convenience function' is something like the timeit 
functions or subprocess.call that create a class instance, call a method 
(or two) on the instance, and then discard the instance while returning 
the result of calling methods. For the common case handled by the 
function, the implementation via a class with methods is a detail that 
the user hardly need know about.


Using a function interface to create and return a class is something else.

--
Terry Jan Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

2013-05-03 Thread Paul Moore

While reviewing the behaviour of Vinay's "distil" installer tool (see
distutils-sig for details, but it's not relevant here) I have found what I
think is a flaw in the behaviour of the py.exe launcher for Windows.

To recap for people unfamiliar with the launcher, it emulates #! line
interpretation on Windows, interpreting commonly used forms from Unix and
launching the appropriate installed Python interpreter (finding its
location from the registry, as python.exe may not be on PATH).

The problem is with the interpretation of #!/usr/bin/env python. The
launcher treats this the same as #!/usr/bin/python, launching the "default"
Python. But that is *not* what the equivalent line does on Unix, where it
launches the *currently active* Python (a crucial difference when there is
an active virtualenv). The result is that a script written to run with the
active Python works on Unix as expected, but can use an unexpected version
of Python on Windows. This is particularly unpleasant when the program in
question is an (un)installer like distil!

I would propose that the behaviour of the launcher on Windows should be
changed when it encounters specifically the hashbang line #!/usr/bin/env
python. In that case, it should search PATH for a copy of python.exe, and
if it finds one, use that. If there is no python.exe on PATH, it should
fall back to the same version of Python as would have been used if the line
were #!/usr/bin/python.

This will mean that scripts written with #!/usr/bin/env python will behave
the same on Unix and Windows in the presence of activated virtualenvs.

Would people be happy with this change? If so I will open an issue on
bugs.python.org. I can look at producing a patch, as well.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?


Guido van Rossum wrote:

I haven't seen code in the style that
Greg proposes in decades,


What style are you talking about here?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?


Eli Bendersky wrote:
I'm just curious what it is about enums that sets everyone on a "let's 
make things safer" path. Python is about duck typing, it's absolutely 
"unsafe" in the static typing sense, in the most fundamental ways 
imaginable.


This isn't about catching bugs in the program, it's
about validating user input. That's a common enough
task that it deserves to have a convenient way to
do it correctly.

Imagine if int() had the property that, as well as
accepting strings of decimal digits, it also accepted
the string "guido" and returned his birthday as a
DateTime object. When people complain, they're told
it's okay, you only need to write

   if s != "guido":
  x = int(s)
   else:
  raise ValueError

What would you think of that situation?


Why is an Enum different than any other class?


It's not, that's the whole point. IMO it deserves to
have a convenient way of mapping a valid string
representation -- and nothing else -- to a valid value,
just as much as any other type does.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing  wrote:
> Eli Bendersky wrote:
> > I'm just curious what it is about enums that sets everyone on a "let's 
> > make things safer" path. Python is about duck typing, it's absolutely 
> > "unsafe" in the static typing sense, in the most fundamental ways 
> > imaginable.
> 
> This isn't about catching bugs in the program, it's
> about validating user input. That's a common enough
> task that it deserves to have a convenient way to
> do it correctly.

+1. An enum is basically a bidirectional mapping between some raw
values and some "nice" instances, so it deserves a well-defined lookup
operation in each direction.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-03 Thread Guido van Rossum

On Fri, May 3, 2013 at 4:08 PM, Greg Ewing  wrote:
> Guido van Rossum wrote:
>>
>> I haven't seen code in the style that
>> Greg proposes in decades,

> What style are you talking about here?

Code that wants to validate a string the user typed as input. Web
forms just don't work that way. (Command-line flags are a special
case, and there are a slew of specialized parsers for that case.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-05-03 Thread Steven D'Aprano

On 03/05/13 20:37, Paul Moore wrote:

On 2 April 2013 01:47, Daniel Holth wrote:

This PEP proposes to fix these problems by re-publicising the feature,
defining the .pyz and .pyzw extensions as “Python ZIP Applications”
and “Windowed Python ZIP Applications”, and providing some simple
tooling to manage the format.

There is a bug in Windows Powershell, which is apparently due to a bug in
the underlying FindExecutable API, that can fail to recognise extensions
which are longer than 3 characters properly.

Are you referring to this one?

https://groups.google.com/group/microsoft.public.vb.general.discussion/browse_thread/thread/109aaa1c7d6a31a7/76f9a67c39002178?hl=en

That's pretty old, is it still a problem? Besides, if I'm reading this properly:

http://msdn.microsoft.com/en-us/library/bb776419(VS.85).aspx

the issue is that they should be using AssocQueryString, not FindExecutable.

Rather than risk obscure bugs, I would suggest restricting the extensions
to 3 characters. For the “Windowed Python ZIP Applications” case, could we
use .pzw as the extension instead of .pyzw?

I've had Linux systems which associated OpenOffice docs with Archive Manager
rather than OpenOffice. It's likely that at least some Linux systems will
likewise decide that .pyz files are archives, not Python files, and open them
in Archive Manager. I don't believe that it is Python's responsibility to work
around bugs in desktop environments' handling of file associations.

Many official Microsoft file extensions are four or more letters, e.g. docx. I
don't see any value in making long-lasting decisions on file extensions based
on (transient?) bugs that aren't our responsibility.

--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On 4 May 2013 05:17, "Georg Brandl"  wrote:
>
> Am 03.05.2013 11:40, schrieb Steven D'Aprano:
> > On 03/05/13 18:42, Antoine Pitrou wrote:
> >> Le Fri, 3 May 2013 09:14:22 +1000, Nick Coghlan  a
> >> écrit :
> >
> >>> I would suggest moving the field names into the class header for a
class
> >>> based convenience API:
> >>>
> >>> class Animal(Enum, members='cat dog'): pass
> >>
> >> This looks good to me (assuming some people don't like the special
> >> attribute scheme).
> >
> > The problem is that this is not an expression, it is a statement. The
> > advantage of the convenience function is not just that it is shorter,
but
> > that it is an expression.
>
> But using that expression in any form other than
>
> NAME = Enum('NAME', ...)
>
> will again result in an unpicklable enum, which was the point of this
thread.

Right, if all we want is a functional API that doesn't support pickling of
the resulting class, that's trivial.

What I'm after is a convenience API that supports *autonumbering*, as a
trivial replacement for code that currently uses "range(n)". A class
statement is perfectly acceptable to me for that purpose.

Independently of that, I do like the notion of a "types.set_name(cls,
dotted_name)" API that alters __name__ and __module__, while leaving
__qualname__ alone.

Cheers,
Nick.

>
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 4 May 2013 00:17, "Eli Bendersky"  wrote:
>
>
>
>
> On Fri, May 3, 2013 at 6:34 AM, Greg Ewing 
wrote:
>>
>> Barry Warsaw wrote:
>>>
>>> I still don't get it why this is an issue though, or at least why this
is
>>> different than any other getattr on any other class,
>>
>>
>> It's not a problem that getattr() has this behaviour.
>> What I'm questioning is the idea that getattr() should
>> be the only provided way of doing a name->enum lookup,
>> because that will require everyone to do extra checks
>> to ensure safety.
>
>
> I'm just curious what it is about enums that sets everyone on a "let's
make things safer" path. Python is about duck typing, it's absolutely
"unsafe" in the static typing sense, in the most fundamental ways
imaginable. When programmatically invoking a method on a class (say some
sort of RPC), we don't check that the class is of the correct type. We
invoke a method, and if it quacks, that's a good enough duck. If it was
actually the wrong class, something will break later. EAFP Is a central
Python tenet, whether we like it or not. If one looks for static
guarantees, Python surely shouldn't be the preferred language, no?
>
> And concretely, how is this case different from any programmatic
attribute access in Python objects? You can pass dunders to getattr() and
it probably wasn't what you meant, but Python does not do this type
checking for you. Why is an Enum different than any other class?

The only reason to use enums at all is to improve logging and error
messages. Thus, designing the API and behaviour of an enum type is mostly a
matter of asking "What mistakes are developers likely to make?" and "How
can the enum design help guide them towards a suitable solution?". The
answers are a combination of API design and providing appropriate details
in error messages.

If a developer doesn't care about those two questions then they would just
use the raw underlying values.

Cheers,
Nick.

>
> Eli
>
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 4 May 2013 09:34, "Guido van Rossum"  wrote:
>
> On Fri, May 3, 2013 at 4:08 PM, Greg Ewing 
wrote:
> > Guido van Rossum wrote:
> >>
> >> I haven't seen code in the style that
> >> Greg proposes in decades,
>
> > What style are you talking about here?
>
> Code that wants to validate a string the user typed as input. Web
> forms just don't work that way. (Command-line flags are a special
> case, and there are a slew of specialized parsers for that case.)

And for code that really needs it, it is straightforward to use dir(MyEnum)
and isinstance(obj, MyEnum) to get an exact mapping of names to values that
also accounts for aliases.

Cheers,
Nick.

>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

2013-05-03 Thread Brian Curtin

On Fri, May 3, 2013 at 3:23 PM, Paul Moore  wrote:
> I would propose that the behaviour of the launcher on Windows should be
> changed when it encounters specifically the hashbang line #!/usr/bin/env
> python. In that case, it should search PATH for a copy of python.exe, and if
> it finds one, use that. If there is no python.exe on PATH, it should fall
> back to the same version of Python as would have been used if the line were
> #!/usr/bin/python.
>
> This will mean that scripts written with #!/usr/bin/env python will behave
> the same on Unix and Windows in the presence of activated virtualenvs.
>
> Would people be happy with this change? If so I will open an issue on
> bugs.python.org. I can look at producing a patch, as well.

Sounds reasonable to me.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-05-03 Thread Glenn Linderman


On 5/3/2013 6:41 PM, Steven D'Aprano wrote:
Many official Microsoft file extensions are four or more letters, e.g. 
docx. I don't see any value in making long-lasting decisions on file 
extensions based on (transient?) bugs that aren't our responsibility. 


+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-05-03 Thread Stephen J. Turnbull

Steven D'Aprano writes:

 > > Rather than risk obscure bugs, I would suggest restricting the extensions
 > > to 3 characters. For the “Windowed Python ZIP Applications” case, could we
 > > use .pzw as the extension instead of .pyzw?

+0

 > Many official Microsoft file extensions are four or more letters,
 > e.g. docx.

Give us a non-MS example, please.  Nobody in their right mind would
clash with a major MS product's naming conventions.  Not even if their
file format implements Digital-Ocular Coordination eXtensions.  And a
shell that borks the Borg's extensions won't make it in the market.

 > I don't see any value in making long-lasting decisions
 > on file extensions based on (transient?) bugs that aren't our
 > responsibility.

Getting these associations right is worth *something* to Python.  I'm
not in a position to say more than "it's positive".  But I don't see
why we really care about what the file extensions are as long as they
serve the purpose of making it easy to figure out which files are in
what format in a names-only list.

I have to admit that "Windowed Python ZIP Application" is probably
something I personally will only ever consider as an hypothesis,
though.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

On Sat, May 4, 2013 at 12:18 PM, Brian Curtin  wrote:
> On Fri, May 3, 2013 at 3:23 PM, Paul Moore  wrote:
>> I would propose that the behaviour of the launcher on Windows should be
>> changed when it encounters specifically the hashbang line #!/usr/bin/env
>> python. In that case, it should search PATH for a copy of python.exe, and if
>> it finds one, use that. If there is no python.exe on PATH, it should fall
>> back to the same version of Python as would have been used if the line were
>> #!/usr/bin/python.
>>
>> This will mean that scripts written with #!/usr/bin/env python will behave
>> the same on Unix and Windows in the presence of activated virtualenvs.
>>
>> Would people be happy with this change? If so I will open an issue on
>> bugs.python.org. I can look at producing a patch, as well.
>
> Sounds reasonable to me.

Also to me.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-03 Thread Georg Brandl

Am 04.05.2013 01:22, schrieb Antoine Pitrou:
> On Sat, 04 May 2013 11:15:17 +1200
> Greg Ewing  wrote:
>> Eli Bendersky wrote:
>> > I'm just curious what it is about enums that sets everyone on a "let's 
>> > make things safer" path. Python is about duck typing, it's absolutely 
>> > "unsafe" in the static typing sense, in the most fundamental ways 
>> > imaginable.
>> 
>> This isn't about catching bugs in the program, it's
>> about validating user input. That's a common enough
>> task that it deserves to have a convenient way to
>> do it correctly.
> 
> +1. An enum is basically a bidirectional mapping between some raw
> values and some "nice" instances, so it deserves a well-defined lookup
> operation in each direction.

Agreed.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

2013-05-03 Thread Steven D'Aprano

On 04/05/13 15:13, Stephen J. Turnbull wrote:

Steven D'Aprano writes:

  > > Rather than risk obscure bugs, I would suggest restricting the extensions
  > > to 3 characters. For the “Windowed Python ZIP Applications” case, could we
  > > use .pzw as the extension instead of .pyzw?

+0

  > Many official Microsoft file extensions are four or more letters,
  > e.g. docx.

Give us a non-MS example, please.  Nobody in their right mind would
clash with a major MS product's naming conventions.  Not even if their
file format implements Digital-Ocular Coordination eXtensions.  And a
shell that borks the Borg's extensions won't make it in the market.

I'm afraid I don't understand your question. Are you suggesting that four 
letter extensions are restricted to Microsoft products? If so, that would be an 
excellent reason to avoid .pyzw, but I don't believe that is the case.

Common 4+ letter extensions include .html, .tiff, .jpeg, .mpeg, .midi, .java 
and .torrent.

--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sat, May 4, 2013 at 4:10 PM, Georg Brandl  wrote:
> Am 04.05.2013 01:22, schrieb Antoine Pitrou:
>> On Sat, 04 May 2013 11:15:17 +1200
>> Greg Ewing  wrote:
>>> Eli Bendersky wrote:
>>> > I'm just curious what it is about enums that sets everyone on a "let's
>>> > make things safer" path. Python is about duck typing, it's absolutely
>>> > "unsafe" in the static typing sense, in the most fundamental ways
>>> > imaginable.
>>>
>>> This isn't about catching bugs in the program, it's
>>> about validating user input. That's a common enough
>>> task that it deserves to have a convenient way to
>>> do it correctly.
>>
>> +1. An enum is basically a bidirectional mapping between some raw
>> values and some "nice" instances, so it deserves a well-defined lookup
>> operation in each direction.

As I see it, there are 3 possible ways forward here:

1. The current PEP, offering only "getattr(MyEnum, name)".

If code needs to ensure non-enum values are detected immediately (such
as during translation of user input entered at a command prompt), then
they can either create a separate mapping using:

lookup = {m.name, m for m in (getattr(MyEnum, name) for name in
dir(MyEnum)) if isinstance(m, MyEnum)}

or else create a lookup function:

def getmember(enum, name):
m = getattr(enum, name, None)
if not isinstance(m, enum):
raise KeyError("{!r} is not a member of {!r}".format(name, enum))
return m

2. We restore __getitem__ on EnumMetaclass *solely* for member lookup
by name (the "getmember" functionality above). This would leave
__call__ used for the reverse lookup (value to member and hence name)
and __getitem__ for the forward lookup (name to member and hence
value) (Note: given Ethan's comments about his current implementation,
I believe this actually fits nicely with the way
EnumMetaclass.__getattr__ is already implemented)

3. We offer my earlier suggestion of an "as_dict()" method on the
metaclass, which implements the mapping calculation above. As others
pointed out, this has the same name clash problem as offering
additional non-special methods on namedtuple objects.

I'm now -1 on my own as_dict() suggestion, due to the general name
clash problem for arbitrary enums.

Options 1 and 2 both sound reasonable to me, although I have a
preference for 2 due to the ability to produce a more appropriate
error message when the lookup fails.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?


Guido van Rossum wrote:

Code that wants to validate a string the user typed as input. Web
forms just don't work that way.


Maybe "validation" was a misleading term to use. To be
more precise, I'm talking about taking input to the
program (it needn't come directly from a user, it could
be read from a file or database) that is supposed to
be the name of a Color, and turning it into a Color
instance.

For that purpose, it's convenient to have a function
with only two possible outcomes: it either returns a
Color instance, or raises a ValueError.

The point is that you *shouldn't* have to perform a
separate validation step. You should be able to use
EAFP -- go ahead and perform the conversion, but be
prepared to catch a ValueError at some level and
report it to the user.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] enum discussion: can someone please summarize open issues?


Nick Coghlan wrote:

1. The current PEP, offering only "getattr(MyEnum, name)".

>

2. We restore __getitem__ on EnumMetaclass *solely* for member lookup
by name


3. Use keyword arguments to distinguish two different
ways of calling the enum class:

   MyEnum(value = 1) --> lookup by value
   MyEnum(name = "foo") --> lookup by name

MyEnum(1) could be made equivalent to MyEnum(value = 1)
if it's thought that lookup by value will be the most
common or natural case.

Pros: Explicit is better than implicit.

Cons: Not so convenient to get a type-conversion function
to pass to other things.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"