Re: [Python-Dev] Language Summit notes

[Armin Rigo]

Hi,

On 10 April 2014 22:12, Paul Moore  wrote:
> I agree. I'd like to see a clear explanation of what advantages (and
> disadvantages!) CFFI gives over ctypes, as well as the plan for
> inclusion and how the inevitable confusion over whether to use ctypes
> or cffi will be handled.  (...)

I can't judge exactly what was told in the Language Summit, but here
is my own position about CFFI. Code-wise, we're in precisely the same
spot as last year.  The usage of CFFI seems to be growing a lot.
However, it's not in any stdlib-ready state right now.

Why not?  Because we have a plan to go forward and fix the main issues
people seem to be having: when used in "API mode" there is some
building-C-sources-and-compiling-them going on under your feet;
however, "explicit is better than implicit" seems to apply here too.
Thus, it seems that the basic model might be changed toward a variant
in which you put your C declarations into some separate file that you
need to execute once, in order to build and compile a regular C
extension module.

This would be superficial, but change the perception of CFFI to be "a
preprocessor that produces C extension modules".

This affects the "API mode" but not the "ABI mode" (which is basically
the same as ctypes, modulo the syntax).


A bientôt,

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

Re: [Python-Dev] Language Summit notes

[Nick Coghlan]

On 11 Apr 2014 05:39, "Armin Rigo"  wrote:
>
> Hi,
>
> On 10 April 2014 22:12, Paul Moore  wrote:
> > I agree. I'd like to see a clear explanation of what advantages (and
> > disadvantages!) CFFI gives over ctypes, as well as the plan for
> > inclusion and how the inevitable confusion over whether to use ctypes
> > or cffi will be handled.  (...)
>
> I can't judge exactly what was told in the Language Summit, but here
> is my own position about CFFI. Code-wise, we're in precisely the same
> spot as last year.  The usage of CFFI seems to be growing a lot.
> However, it's not in any stdlib-ready state right now.
>
> Why not?  Because we have a plan to go forward and fix the main issues
> people seem to be having: when used in "API mode" there is some
> building-C-sources-and-compiling-them going on under your feet;
> however, "explicit is better than implicit" seems to apply here too.
> Thus, it seems that the basic model might be changed toward a variant
> in which you put your C declarations into some separate file that you
> need to execute once, in order to build and compile a regular C
> extension module.
>
> This would be superficial, but change the perception of CFFI to be "a
> preprocessor that produces C extension modules".
>
> This affects the "API mode" but not the "ABI mode" (which is basically
> the same as ctypes, modulo the syntax).

This is along the lines of what Alex said at the summit (i.e. it wasn't
proposed for 3.4 because you didn't consider it stdlib ready yet). The
clearer separation of the build and import steps definitely sounds
promising, as the current implicit approach poses challenges getting cffi
extensions to play nice with wheel based distribution.

Cheers,
Nick.

>
>
> A bientôt,
>
> Armin.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

[Paul Moore]

On 11 April 2014 10:36, Armin Rigo  wrote:
> This would be superficial, but change the perception of CFFI to be "a
> preprocessor that produces C extension modules".

Thanks, that clarification helps a lot. Does this mean that "API-mode"
CFFI is competing with things like swig (which is not used much these
days, as far as I know) and Cython (which is used a lot in the numeric
community)? ("ABI-mode" CFFI is obviously directly competing with
ctypes).

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

[Python-Dev] flock in Python 3

[Jakub QB Dorňák]

Hi all,

writing a threaded application I've been surprised that there is no object api 
for fcntl.flock implementing __enter__() and __exit__() methods to be used with 
'with' statement.
I have written one (https://pypi.python.org/pypi), but I wonder whether this 
could get into the Python Standard Library.

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2014-04-04 - 2014-04-11)
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:
  open4567 (+17)
  closed 28405 (+29)
  total  32972 (+46)

Open issues with patches: 2096 


Issues opened (32)
==

#21015: support SSL_CTX_set_ecdh_auto on newer OpenSSLs
http://bugs.python.org/issue21015  reopened by ned.deily

#21156: Consider moving importlib.abc.InspectLoader.source_to_code() t
http://bugs.python.org/issue21156  opened by brett.cannon

#21157: Update imp docs for a PEP 451 world
http://bugs.python.org/issue21157  opened by brett.cannon

#21158: Windows installer service could not be accessed (Python bug!)
http://bugs.python.org/issue21158  opened by thecheater887

#21159: configparser.InterpolationMissingOptionError is not very intui
http://bugs.python.org/issue21159  opened by Claudiu.Popa

#21160: incorrect comments in nturl2path.py
http://bugs.python.org/issue21160  opened by Jurko.Gospodnetić

#21162: code in multiprocessing.pool freeze if inside some code from s
http://bugs.python.org/issue21162  opened by Ivan.K

#21163: asyncio task possibly incorrectly garbage collected
http://bugs.python.org/issue21163  opened by richard.kiss

#21164: print unicode in Windows console
http://bugs.python.org/issue21164  opened by LeslieK

#21165: Optimize str.translate() for replacement with substrings and n
http://bugs.python.org/issue21165  opened by haypo

#21167: float('nan') returns 0.0 on Python compiled with icc
http://bugs.python.org/issue21167  opened by hniksic

#21169: getpass.getpass() fails with non-ASCII characters in prompt
http://bugs.python.org/issue21169  opened by Arfrever

#21170: Incorrect signature for unittest.TestResult.startTestRun(), .s
http://bugs.python.org/issue21170  opened by Volodymyr.Sapsai

#21171: Outdated usage str.encode('rot-13') in rot13 codec
http://bugs.python.org/issue21171  opened by Pix

#21173: WeakKeyDictionary.__len__ fragile w/ _IterationGuards
http://bugs.python.org/issue21173  opened by pjenvey

#21177: ValueError: byte must be in range(0, 256)
http://bugs.python.org/issue21177  opened by zart

#21178: doctest cause warnings in tests using generators
http://bugs.python.org/issue21178  opened by oluensdorf

#21180: Cannot efficiently create empty array.array of given size, inc
http://bugs.python.org/issue21180  opened by pfalcon

#21183: Doctest capture only AssertionError but not printed text
http://bugs.python.org/issue21183  opened by osantana

#21184: statistics.pvariance with known mean does not work as expected
http://bugs.python.org/issue21184  opened by steven.daprano

#21186: RawConfigParser __name__ option handling inconsistent
http://bugs.python.org/issue21186  opened by Adam.Groszer

#21188: Broken link
http://bugs.python.org/issue21188  opened by tiposchi

#21189: Broken link to patch
http://bugs.python.org/issue21189  opened by tiposchi

#21192: Idle: Print filename when running a file from editor
http://bugs.python.org/issue21192  opened by terry.reedy

#21193: pow(a, b, c) should not raise TypeError when b is negative and
http://bugs.python.org/issue21193  opened by josh.rosenberg

#21194: json.dumps with ensure_ascii=False doesn't escape control char
http://bugs.python.org/issue21194  opened by weeble

#21195: None float format: incomplete documentation
http://bugs.python.org/issue21195  opened by lebigot

#21196: Name mangling example in Python tutorial
http://bugs.python.org/issue21196  opened by chandan

#21197: venv does not create lib64 directory and appropriate symlinks
http://bugs.python.org/issue21197  opened by BinaryKhaos

#21198: Minor tarfile documentation bug
http://bugs.python.org/issue21198  opened by lurchman

#21199: Python on 64-bit Windows uses signed 32-bit type for read leng
http://bugs.python.org/issue21199  opened by Matt.Mackall

#21200: pkgutil.get_loader() fails on "__main__"
http://bugs.python.org/issue21200  opened by eric.snow



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

#21200: pkgutil.get_loader() fails on "__main__"
http://bugs.python.org/issue21200

#21198: Minor tarfile documentation bug
http://bugs.python.org/issue21198

#21188: Broken link
http://bugs.python.org/issue21188

#21173: WeakKeyDictionary.__len__ fragile w/ _IterationGuards
http://bugs.python.org/issue21173

#21160: incorrect comments in nturl2path.py
http://bugs.python.org/issue21160

#21152: Idle: timed autosave for shell (and maybe editor) window
http://bugs.python.org/issue21152

#21132: Failure to import win32api
http://bugs.python.org/issue21132

#21126: Integrate doctest.run_docstring_examples() with unittest
http://bugs.python.org/issue21126

#21120: PyArena type is used in headers from the limited API
http://bugs.python.org/issue21120

#21114: wsgiref.simple_server doesn't handle multi-line headers correc
http://bugs.python.org/issue21114

#21

Re: [Python-Dev] flock in Python 3

[Terry Reedy]

On 4/11/2014 8:58 AM, Jakub QB Dorňák wrote:


writing a threaded application I've been surprised that there is no
object api for fcntl.flock implementing __enter__() and __exit__()
methods to be used with 'with' statement.


Several things have been turned into context managers because someone 
filed a request on the tracker. I do not see one for flock.



I have written one
(https://pypi.python.org/pypi), but I wonder whether this could get
into the Python Standard Library.


It might if you open an issue and submitted a patch.

--
Terry Jan Reedy


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

Re: [Python-Dev] flock in Python 3

[Benjamin Peterson]

On Fri, Apr 11, 2014, at 5:58, Jakub QB Dorňák wrote:
> Hi all,
> 
> writing a threaded application I've been surprised that there is no
> object api for fcntl.flock implementing __enter__() and __exit__()
> methods to be used with 'with' statement.
> I have written one (https://pypi.python.org/pypi), but I wonder whether
> this could get into the Python Standard Library.

That link PyPi link is broken.

I think it would be nicer to have a high-level API for cross-platform
file locking. IIRC, flock can be rather non-portable.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Christian Tismer]

Ah, now I see it.

For some reason, I forgot that the dict is always newly created.
That was really wrong thinking. Sorry!

On 11/04/14 05:47, Guido van Rossum wrote:
> I'm not sure what you're worried about here. Modifying kwds doesn't
> actually modify the dict that was passed in. So are you just talking about
> the style issue? Or would you also object to this:
> 
> def foo(x=1):
> x += 1
> 

No, this is ok, although I personally tend not to modify args.

No, it was just my temporary forgetting that the star
args/kwds are always in a new container, and the whole reasoning chain
was pointless, therefore.

Thanks and cheers - Chris


> On Thu, Apr 10, 2014 at 10:12 PM, Christian Tismer 
> wrote:
> 
>> Hi guys,
>>
>> I tried to find advice for hours, but failed so fer, so here is my
>> question:
>>
>> Whenever I think to adopt a new module that does a good job, I always
>> can't stand the temptation to look at the coding style and certain
>> principles.
>>
>> Then I rather often see things like this:
>>
>> class someclass(object):
>> # note that there is no comment about argument destruction...
>>
>> def __init__(self, **kwargs):
>> first_arg = kwargs.pop('option_1', somedefault)
>> ...
>> nth_arg = kwargs.pop('option_n', somedefault')
>> ...
>>
>> That is:
>> There are arguments "consumed" rigorously by the __init__ of a class,
>> although it would be equivalent to use kwargs.get(..., ...).
>>
>> Happened to me again, today and blocked me completely, since I don't
>> know if I saw bad programming style or if I'm mislead.
>>
>> I agree there are valid cases when if makes sense to filter out some
>> arguments
>> that a subsequently called super() might not be able to handle.
>> Bu even then, I would probably have a copy and make the filtering more
>> explicit.
>>
>> But most of the time, there is no reason for using this pattern, and there
>> is also no comment stating that the argument dict is modified by the callee
>> for no good reason.
>>
>> I always used the policy that arguments are never changed by a function,
>> unless explicitly stated.
>> But since I see this pattern quite frequently, I wanted to ask if I am
>> right by
>> thinking this way, or if the general policy is more like "arguments may be
>> destroyed by default".
>>
>> What do you think? Is this bad style and should be noticed somewhere,
>> or is the caller supposed to protect the arguments, or are my worries
>> useless?
>>
>> Thanks & cheers -- Chris
>>


-- 
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Christian Tismer]

Thank you too, Tres.
Somehow I had a brain shortcut and forgot that
the dict is locally generated, *because* of the stars.

Good to become adjusted and restarted, sorry about the noise.

ciao - Chris


On 11/04/14 05:48, Tres Seaver wrote:
> On 04/10/2014 10:12 PM, Christian Tismer wrote:
> 
>> I always used the policy that arguments are never changed by a 
>> function, unless explicitly stated. But since I see this pattern 
>> quite frequently, I wanted to ask if I am right by thinking this 
>> way, or if the general policy is more like "arguments may be 
>> destroyed by default".
> 
>> What do you think? Is this bad style and should be noticed 
>> somewhere, or is the caller supposed to protect the arguments,
>> or are my worries useless?
> 
> The caller can't know or care that the function / method pops 
> arguments::
> 
> $ python Python 2.7.3 (default, Feb 27 2014, 19:58:35) [GCC 4.6.3] 
> on linux2 Type "help", "copyright", "credits" or "license" for
> more information.
 def foo(**kw):
> ... bar = kw.pop('bar', 'BAR') ... print 'bar: %s' % bar 
> ... print 'kw: %s' % kw ...
 foo()
> bar: BAR kw: {}
 foo(bar='baz')
> bar: baz kw: {}
 foo(bar='baz', bam='qux')
> bar: baz kw: {'bam': 'qux'}
 mykw = {'bar': 'baz', 'bam': 'qux'} foo(**mykw)
> bar: baz kw: {'bam': 'qux'}
 mykw
> {'bam': 'qux', 'bar': 'baz'}
> 
> because the caller gets its own copy of 'kw', even when called
> with an existing dict.
> 
> 
> Tres.
> 
> ___ Python-Dev mailing 
> list Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/tismer%40stackless.com
>
>
> 
-- 
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

[Maciej Fijalkowski]

On Fri, Apr 11, 2014 at 2:22 PM, Paul Moore  wrote:
> On 11 April 2014 10:36, Armin Rigo  wrote:
>> This would be superficial, but change the perception of CFFI to be "a
>> preprocessor that produces C extension modules".
>
> Thanks, that clarification helps a lot. Does this mean that "API-mode"
> CFFI is competing with things like swig (which is not used much these
> days, as far as I know) and Cython (which is used a lot in the numeric
> community)? ("ABI-mode" CFFI is obviously directly competing with
> ctypes).

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

[Python-Dev] Receiving email updates for the bug tracker

[Antony Lee]

Hi,
Sorry for the slightly off-topic(?) question but I would like to know how
to receive email notifications for activity on bugs I've opened on the
bugs.python.org -- so far I don't receive anything even though I'm on the
nosy list.
Thanks,
Antony
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Receiving email updates for the bug tracker

[Brett Cannon]

On Fri, Apr 11, 2014 at 1:47 PM, Antony Lee  wrote:

> Hi,
> Sorry for the slightly off-topic(?) question but I would like to know how
> to receive email notifications for activity on bugs I've opened on the
> bugs.python.org -- so far I don't receive anything even though I'm on the
> nosy list.
>

Should be automatic. I would check your email address in your account
settings.

-Brett


>  Thanks,
> Antony
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Receiving email updates for the bug tracker

[Brett Cannon]

On Fri, Apr 11, 2014 at 3:25 PM, Antony Lee  wrote:

> Nope, the email is correct...
>

Then you can try reporting a bug at
http://psf.upfronthosting.co.za/roundup/meta/


>
> 2014-04-11 12:12 GMT-07:00 Brett Cannon :
>
>
>>
>>
>> On Fri, Apr 11, 2014 at 1:47 PM, Antony Lee wrote:
>>
>>> Hi,
>>> Sorry for the slightly off-topic(?) question but I would like to know
>>> how to receive email notifications for activity on bugs I've opened on the
>>> bugs.python.org -- so far I don't receive anything even though I'm on
>>> the nosy list.
>>>
>>
>> Should be automatic. I would check your email address in your account
>> settings.
>>
>> -Brett
>>
>>
>>>  Thanks,
>>> Antony
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>>
>>>
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Chris Barker]

On Thu, Apr 10, 2014 at 7:12 PM, Christian Tismer wrote:

> Then I rather often see things like this:
>
> class someclass(object):
> # note that there is no comment about argument destruction...
>
> def __init__(self, **kwargs):
> first_arg = kwargs.pop('option_1', somedefault)
> ...
> nth_arg = kwargs.pop('option_n', somedefault')
> ...
>

While it's been clarified that this isn't dangerous, I find it to be a
really annoying style, as you've lost the opurtuniyt to docuemnt somethign
in the signature. Is:

def __init__(self, option_1=some_default, option_n=some_default,
**kwargs):
first_arg = kwargs.pop('option_1')
nth_arg = kwargs.pop('option_n')

*that* much harder to write?

And many of these come with virtually no docstring, either.

oh well,

  -Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Receiving email updates for the bug tracker

[Guido van Rossum]

Did you check your spam folder?


On Fri, Apr 11, 2014 at 1:47 PM, Antony Lee  wrote:

> Hi,
> Sorry for the slightly off-topic(?) question but I would like to know how
> to receive email notifications for activity on bugs I've opened on the
> bugs.python.org -- so far I don't receive anything even though I'm on the
> nosy list.
> Thanks,
> Antony
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


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

Re: [Python-Dev] Receiving email updates for the bug tracker

[Antony Lee]

Nope, the email is correct...

2014-04-11 12:12 GMT-07:00 Brett Cannon :

>
>
>
> On Fri, Apr 11, 2014 at 1:47 PM, Antony Lee wrote:
>
>> Hi,
>> Sorry for the slightly off-topic(?) question but I would like to know how
>> to receive email notifications for activity on bugs I've opened on the
>> bugs.python.org -- so far I don't receive anything even though I'm on
>> the nosy list.
>>
>
> Should be automatic. I would check your email address in your account
> settings.
>
> -Brett
>
>
>>  Thanks,
>> Antony
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Christian Tismer]

Hi Chris,

On 11/04/14 21:50, Chris Barker wrote:
> On Thu, Apr 10, 2014 at 7:12 PM, Christian Tismer wrote:
> 
>> Then I rather often see things like this:
>>
>> class someclass(object):
>> # note that there is no comment about argument destruction...
>>
>> def __init__(self, **kwargs):
>> first_arg = kwargs.pop('option_1', somedefault)
>> ...
>> nth_arg = kwargs.pop('option_n', somedefault')
>> ...
>>
> 
> While it's been clarified that this isn't dangerous, I find it to be a
> really annoying style, as you've lost the opurtuniyt to docuemnt somethign
> in the signature. Is:
> 
> def __init__(self, option_1=some_default, option_n=some_default,
> **kwargs):
> first_arg = kwargs.pop('option_1')
> nth_arg = kwargs.pop('option_n')
> 
> *that* much harder to write?
> 
> And many of these come with virtually no docstring, either.

Thank you for re-validating my rant, after my wrong start was clarified.
Yes, the style is of course annoying, still.

This is the style of
"""hey look how cool I am, just taking an interface, picking args if
they happen to be there and otherwise not treating them""".

So while I'm still ashamed of my mis-interpretion, I am happy to still
not like that very much.

At least for myself, I like to be way more explicit and tell actively
what I expect as arguments, what I do care about and what not, just to
make sure that people see right by looking at the interface what they
may ignore and what they should probably put in as an argument.

Actually, putting so many defaults in without documenting that in the
interface is this new-fangled sloppiness that is perceived as cool-ness.

May be I am getting old, but I dislike this and tend to tell much more
in the interface. And not in the 35th iteration, but when writing the
first public version.

This is because I don't want to throw an interface at somebody, but to
discuss and improve it, and for that I put comments in that invite to
agree or create a better version.

I have these style problems with several modules that I am reluctant to
use, therefore. I know that I'm pretty alone with that. But my idea
of a published module is such that it should try to motivate why it is
doing things in which way, and why it thinks this is good to do.

Doing that not and nothing instead is my definition of "sloppy".

(interested people may get the actual module from me why this came up)

cheers -- Chris


-- 
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Receiving email updates for the bug tracker

[Antony Lee]

Actually that was a better idea...
Antony


2014-04-11 13:20 GMT-07:00 Guido van Rossum :

> Did you check your spam folder?
>
>
> On Fri, Apr 11, 2014 at 1:47 PM, Antony Lee wrote:
>
>> Hi,
>> Sorry for the slightly off-topic(?) question but I would like to know how
>> to receive email notifications for activity on bugs I've opened on the
>> bugs.python.org -- so far I don't receive anything even though I'm on
>> the nosy list.
>> Thanks,
>> Antony
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Greg Ewing]

On 11/04/14 21:50, Chris Barker wrote:


On Thu, Apr 10, 2014 at 7:12 PM, Christian Tismer wrote:


   def __init__(self, **kwargs):
   first_arg = kwargs.pop('option_1', somedefault)
   ...
   nth_arg = kwargs.pop('option_n', somedefault')
   ...


Is:

   def __init__(self, option_1=some_default, option_n=some_default,
**kwargs):

*that* much harder to write?


I've done this kind of thing (extracting arguments out of **kwds)
in various places in PyGUI, but the situation is somewhat special.
Most classes in PyGUI have an api that accepts *any* of the object's
properties as keyword arguments to the constructor, implemented by
code in the base class's __init__ method. It would be impractical
to explicitly document all of them as constructor args, so I don't.
I just say in one place in the docs that this is general behaviour
to be expected of all PyGUI classes.

Sometimes a class needs to treat the initial values of some of its
properties in a special way, instead of just passing them on to the
base __init__. But this is an implementation detail -- having those
particular args appear explicitly in the signature, but not any of
the others, would serve no purpose, and would just clutter up the
function header. In that situation, I find the extract-from-kwds
style is often easier to read.

Also, often I just want to *read* the value of some arguments,
without popping them. Putting all of those in as explicit keyword
args would mean explicitly passing them on to the base __init__,
further cluttering up the code.

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

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Ethan Furman]

On 04/11/2014 02:01 PM, Christian Tismer wrote:


I have these style problems with several modules that I am reluctant to
use, therefore. I know that I'm pretty alone with that.


You are not alone in that.

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

Re: [Python-Dev] arguments policy: **kwargs.pop()

[Christian Tismer]

On 12.04.14 01:55, Ethan Furman wrote:
> On 04/11/2014 02:01 PM, Christian Tismer wrote:
>>
>> I have these style problems with several modules that I am reluctant to
>> use, therefore. I know that I'm pretty alone with that.
>
> You are not alone in that.

Funny not to be alone in being alone in that :-)

hugs -- Chris

-- 
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

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