Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)
Terry Reedy writes: > Ok, I won't add them when a function's name actually makes what it does > obvious. But when I have to spend at least a few minutes reading the > body to make sense of it, I will try to add the summary line that I wish > had been there already. +1 That's a *great* rule-of-thumb! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] add new lambda syntax
I want use coffeescript function syntax to write python lambda expression
so I modified the Grammar file.
```
atom: ('(' [yield_expr|testlist_comp|vararglist] ')' |
'[' [testlist_comp] ']' |
'{' [dictorsetmaker] '}' |
NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME | '->' text
```
but when I write
```
(x,y=1)->x+y
```
the parser doesn't go into vararglist.
any help?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-06-21 - 2013-06-28) 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: open4069 (+12) closed 26027 (+34) total 30096 (+46) Open issues with patches: 1804 Issues opened (40) == #7732: imp.find_module crashes Python if there exists a directory nam http://bugs.python.org/issue7732 reopened by haypo #18135: _ssl module: possible integer overflow for very long strings ( http://bugs.python.org/issue18135 reopened by pitrou #18267: xmlrpc.client documentation multicall example missleading for http://bugs.python.org/issue18267 reopened by ber #18279: IDLE Unit test for RstripExtension.py http://bugs.python.org/issue18279 opened by philwebster #18280: Documentation is too personalized http://bugs.python.org/issue18280 opened by serhiy.storchaka #18281: tarfile defines stat constants http://bugs.python.org/issue18281 opened by christian.heimes #18283: shutil.which() should support bytes http://bugs.python.org/issue18283 opened by Arfrever #18286: Python 3.3 - Slowing down computer http://bugs.python.org/issue18286 opened by jon_irenicus #18287: PyType_Ready() should sanity-check the tp_name field http://bugs.python.org/issue18287 opened by nkoep #18288: Idle 2.7: Run Module does not set __file__ http://bugs.python.org/issue18288 opened by terry.reedy #18289: python.org Interactive interpreter linked with libedit can seg http://bugs.python.org/issue18289 opened by Max.Kaye #18290: json encoder does not support JSONP/JavaScript safe escaping http://bugs.python.org/issue18290 opened by Ztane #18291: codecs.open interprets space as line ends http://bugs.python.org/issue18291 opened by wpk #18292: IDLE Improvements: Unit test for AutoExpand.py http://bugs.python.org/issue18292 opened by JayKrish #18293: ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated http://bugs.python.org/issue18293 opened by mpb #18294: zlib module is not completly 64-bit safe http://bugs.python.org/issue18294 opened by haypo #18295: Possible integer overflow in PyCode_New() http://bugs.python.org/issue18295 opened by haypo #18296: test_os.test_trailers() is failing on AMD64 FreeBSD 9.0 dtrace http://bugs.python.org/issue18296 opened by haypo #18299: Change script_helper to use universal_newlines=True in _assert http://bugs.python.org/issue18299 opened by r.david.murray #18300: script_helper._asert_python should set TERM='' by default. http://bugs.python.org/issue18300 opened by r.david.murray #18301: In itertools.chain.from_iterable() there is no cls argument http://bugs.python.org/issue18301 opened by py.user #18302: test_multiprocessing: test.support.import_module() does not ig http://bugs.python.org/issue18302 opened by haypo #18304: ElementTree gets awkward to use if there is an xmlns http://bugs.python.org/issue18304 opened by brycenesbitt #18305: [patch] Fast sum() for non-numbers http://bugs.python.org/issue18305 opened by Sergey #18306: os.stat gives exception for Windows junctions in v3.3 http://bugs.python.org/issue18306 opened by John.Jefferies #18307: Relative path in co_filename for zipped modules http://bugs.python.org/issue18307 opened by vmurashev #18308: checkRecvmsgAddress wrong in test_socket.py (AIX failures) http://bugs.python.org/issue18308 opened by David.Edelsohn #18309: Make python slightly more relocatable http://bugs.python.org/issue18309 opened by mathias #18312: "make distclean" deletes files under .hg directory http://bugs.python.org/issue18312 opened by eric.smith #18313: In itertools recipes repeatfunc() defines a non-keyword argume http://bugs.python.org/issue18313 opened by py.user #18314: Have os.unlink remove junction points http://bugs.python.org/issue18314 opened by Kim.Gräsman #18315: bufsize parameter not documented in 2.7.5 http://bugs.python.org/issue18315 opened by Terrel.Shumway #18316: Idle 2.7: update to simplify cross-version patches http://bugs.python.org/issue18316 opened by terry.reedy #18317: gettext: DoS via crafted Plural-Forms http://bugs.python.org/issue18317 opened by jwilk #18318: Idle: stop depending on console output http://bugs.python.org/issue18318 opened by terry.reedy #18319: gettext() cannot find translations with plural forms http://bugs.python.org/issue18319 opened by jwilk #18320: idle, pydoc search python on wrong path at make altinstall wit http://bugs.python.org/issue18320 opened by cosmicduck #18321: Multivolume support in tarfile module http://bugs.python.org/issue18321 opened by edulix #18322: test_stat nits http://bugs.python.org/issue18322 opened by pitrou #18323: 'GzipFile' object has no attribute 'extrastart' http://bugs.python.org/issue18323 opened by Laurent.Gautier Most recent 15 issues with no replies (15) == #18320: idle, pydoc search python on wrong path
Re: [Python-Dev] add new lambda syntax
2013/6/28 Pynix Wang
> I want use coffeescript function syntax to write python lambda expression
> so I modified the Grammar file.
>
> ```
> atom: ('(' [yield_expr|testlist_comp|vararglist] ')' |
>'[' [testlist_comp] ']' |
>'{' [dictorsetmaker] '}' |
>NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')
> trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME | '->' text
> ```
>
> but when I write
> ```
> (x,y=1)->x+y
> ```
> the parser doesn't go into vararglist.
>
This grammar is not LL(1) anymore (it's probably LALR now)
when seeing "x", it has the choice between testlist_comp and vararglist,
and the first one is picked.
Python's parser generator only supports LL(1) grammars.
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] add new lambda syntax
On Fri, Jun 28, 2013 at 7:01 PM, Amaury Forgeot d'Arc wrote:
> 2013/6/28 Pynix Wang
>
>> I want use coffeescript function syntax to write python lambda expression
>> so I modified the Grammar file.
>>
>> ```
>> atom: ('(' [yield_expr|testlist_comp|vararglist] ')' |
>>'[' [testlist_comp] ']' |
>>'{' [dictorsetmaker] '}' |
>>NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')
>> trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME | '->' text
>> ```
>>
>> but when I write
>> ```
>> (x,y=1)->x+y
>> ```
>> the parser doesn't go into vararglist.
>>
>
> This grammar is not LL(1) anymore (it's probably LALR now)
> when seeing "x", it has the choice between testlist_comp and vararglist,
> and the first one is picked.
> Python's parser generator only supports LL(1) grammars.
>
Indeed. You may be able to make this work, but you'd have to fold the bits
of vararglist you need into testlist_comp, then reject invalid syntax that
matches the grammar (like "(x=expr for ...)" or "((x+1)=expr)" or
"(*foo=1)") in the compiler. Something like (untested):
testlist_comp: (test|star_expr) ['=' test]( comp_for | (','
(test|star_expr) ['=' test])* [','] )
--
Thomas Wouters
Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] backported Enum
(On June 19, 2013) Barry Warsaw wrote about porting mailman from flufl.enum to the stdlib.enum: > Switching from call syntax to getitem syntax for looking up an > enum member by name, e.g. >-delivery_mode = DeliveryMode(data['delivery_mode']) >+delivery_mode = DeliveryMode[data['delivery_mode']] > Switching from getitem syntax to call syntax for looking up an > enum member by value, e.g. >-return self._enum[value] >+return self._enum(value) > Interesting that these two were exactly opposite from flufl.enum. Is there a reason why these were reversed? I can sort of convince myself that it makes sense because dicts work better with strings than with ints, but ... it seems like such a minor win that I'm not sure it is worth backwards incompatibility. (Of course, I also don't know how much use stdlib.enum has already gotten with the current syntax.) > Switching from int() to .value to get the integer value of an > enum member, e.g. >-return (member.list_id, member.address.email, int(member.role)) >+return (member.list_id, member.address.email, member.role.value) Is just this a style preference? Using a .value attribute certainly makes sense, but I don't see it mentioned in the PEP as even optional, let alone recommended. If you care that the value be specifically an int (as opposed to any object), then a int constructor may be better. > [Some additional changes that mean there will be *some* changes, > which does reduce the pressure for backwards compatibility.] ... > An unexpected difference is that failing name lookups raise a > KeyError instead of a ValueError. I could understand either, as well as AttributeError, since the instance that would represent that value isn't a class attribute. Looking at Enum creation, I think ValueError would be better than TypeError for complaints about duplicate names. Was TypeError chosen because it should only happen during setup? I would also not be shocked if some people expect failed value lookups to raise an IndexError, though I expect they would adapt if they get something else that makes sense. Would it be wrong to create an EnumError that subclasses (ValueError, KeyError, AttributeError) and to raise that subclass from everything but _StealthProperty and _get_mixins? -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On Jun 28, 2013, at 01:07 PM, Jim J. Jewett wrote:
>> Switching from getitem syntax to call syntax for looking up an
>> enum member by value, e.g.
>
>>-return self._enum[value]
>>+return self._enum(value)
>
>> Interesting that these two were exactly opposite from flufl.enum.
>
>Is there a reason why these were reversed?
The individual decisions made (begrudging) sense at the time, although I don't
think it was noticed that the combined effect was to switch the meanings.
Call syntax makes sense for converting a value to an enum because that mirrors
calling built-in types, e.g. int('7'). Getitem syntax makes sense for
lookup-by-name.
>> Switching from int() to .value to get the integer value of an
>> enum member, e.g.
>
>>-return (member.list_id, member.address.email, int(member.role))
>>+return (member.list_id, member.address.email, member.role.value)
>
>Is just this a style preference?
No. I'm not using IntEnums and regular enums don't have an __int__, which
makes sense because their values can be anything. .value is the way to get at
the value. (Note that even though I don't use IntEnums, my values are all
integers. It's just not worth it to change all my imports.)
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On 06/28/2013 01:07 PM, Jim J. Jewett wrote: (On June 19, 2013) Barry Warsaw wrote about porting mailman from flufl.enum to the stdlib.enum: Switching from call syntax to getitem syntax for looking up an enum member by name, e.g. -delivery_mode = DeliveryMode(data['delivery_mode']) +delivery_mode = DeliveryMode[data['delivery_mode']] Switching from getitem syntax to call syntax for looking up an enum member by value, e.g. -return self._enum[value] +return self._enum(value) Interesting that these two were exactly opposite from flufl.enum. Is there a reason why these were reversed? Originally the call syntax was used for both value and name lookup. Various folks were unhappy with that arrangement, and since the use-case that I was thinking of at the time was getting enum members back from databases, etc., I went with EnumClass(value); I still wanted to be able to use name lookups, so lobbied for getitem syntax for that. Nobody noticed this was the opposite of flufl.enum. Oh, I say "I", and it is certainly my reasons, but I no longer remember if was me that initially proposed those specific ideas, and there were certainly many others that agreed. Switching from int() to .value to get the integer value of an enum member, e.g. -return (member.list_id, member.address.email, int(member.role)) +return (member.list_id, member.address.email, member.role.value) Is just this a style preference? Nope. If you want the exact value, accessing `.value` is the way to get it. Using a .value attribute certainly makes sense, but I don't see it mentioned in the PEP as even optional, let alone recommended. I'll look again at the PEP and the docs and make sure that point is clear. If you care that the value be specifically an int (as opposed to any object), then a int constructor may be better. Not entirely sure what you mean by this? Had it been me, I would have subclassed Enum (as, say, FluflEnum) and added `__int__` to it so that those lines would have remained the same. [Some additional changes that mean there will be *some* changes, which does reduce the pressure for backwards compatibility.] ... An unexpected difference is that failing name lookups raise a KeyError instead of a ValueError. I could understand either, as well as AttributeError, since the instance that would represent that value isn't a class attribute. Looking at Enum creation, I think ValueError would be better than TypeError for complaints about duplicate names. Was TypeError chosen because it should only happen during setup? Yes. That particular error can only happen during setup. I would also not be shocked if some people expect failed value lookups to raise an IndexError, though I expect they would adapt if they get something else that makes sense. Would it be wrong to create an EnumError that subclasses (ValueError, KeyError, AttributeError) and to raise that subclass from everything but _StealthProperty and _get_mixins? Wouldn't bother me; I'm not sure what the bar is for adding new exceptions, though. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On Fri, Jun 28, 2013 at 1:30 PM, Ethan Furman wrote: > On 06/28/2013 01:07 PM, Jim J. Jewett wrote: >> (On June 19, 2013) Barry Warsaw wrote about porting mailman from >>> Switching from getitem syntax to call syntax for looking up an >>> enum member by value, e.g. >>> >>> -return self._enum[value] >>> +return self._enum(value) >>> >>> Interesting that these two were exactly opposite from flufl.enum. >> Is there a reason why these were reversed? > Originally the call syntax was used for both value and name lookup. Various > folks were unhappy with that arrangement, and since the use-case that I was > thinking of at the time was getting enum members back from databases, etc., > I went with EnumClass(value); I still wanted to be able to use name lookups, > so lobbied for getitem syntax for that. Nobody noticed this was the > opposite of flufl.enum. > > Oh, I say "I", and it is certainly my reasons, but I no longer remember if > was me that initially proposed those specific ideas, and there were > certainly many others that agreed. I also have a strong preference for the new way of doing this. In Python, type(arg) is usually a constructor or conversion/cast, and that maps reasonably well on what we're doing here with enums -- taking a value and turning it into the corresponding enum (which still shares some properties with that value, and more if it's an IntEnum). Also, this is a no-op (technically, the identity function) if the arg is already a member of that enum. On the other hand, Color['red'] feels more like a lookup -- this is not so much rhyming with the behavior of other classes (classes are rarely mappings) but still the mnemonic tip "foo[bar] is a lookup" should help in remembering the meaning. I have no idea why it was the other way around in flufl.enum, but admittedly neither of these rules are absolute, and it's possible that flufl.enum just evolved that way without conscious decisions, or that it came from taking a different perspective. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On Jun 28, 2013, at 02:11 PM, Guido van Rossum wrote: >I have no idea why it was the other way around in flufl.enum, but >admittedly neither of these rules are absolute, and it's possible that >flufl.enum just evolved that way without conscious decisions, or that >it came from taking a different perspective. The latter, but I think PEP 435 made the right choices, at least for the stdlib version. It doesn't bother me that I had to switch them when porting. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)
On 6/26/2013 9:56 PM, Guido van Rossum wrote: PEP 257 says this on the formatting of multi-line docstrings: """ Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, followed by a more elaborate description. fileinput has docstrings like """ Return the file number of the current file. When no file is currently opened, returns -1. """ and, perhaps neater, """ Return the name of the file currently being read. Before the first line has been read, returns None. """ From the above, I presume these should become """ Return the file number of the current file. When no file is currently opened, returns -1. """ and """ Return the name of the file currently being read. Before the first line has been read, returns None. """ -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
