Re: [Python-Dev] "PyObject *module" for module-level functions?
On 11/04/2013 11:18 PM, Stefan Behnel wrote: Since this only relates to the argument clinic, I assume this change doesn't get in the way of making module level functions real methods of the module, does it? I'm proposing renaming a parameter for Argument-Clinic-generated code. I can't see how this gets in the way of anything. //arry/ ___ 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] "PyObject *module" for module-level functions?
On 5 Nov 2013 17:19, "Stefan Behnel" wrote:
>
> Larry Hastings, 04.11.2013 23:47:
> > When Clinic generates a function, it knows what kind of callable it
> > represents, and it names the first argument (the "PyObject *")
accordingly:
> >
> > * module-level function ("self"),
> > * method ("self"),
> > * class method ("cls"), or
> > * class static ("null").
> >
> > I now boldly propose that for the first one, the module-level function,
the
> > PyObject * parameter should be named "module". The object passed in is
the
> > module object, it's not a "self" in any conventional sense of the word.
> >
> > This would enhance readability, as I assert the name "self" there is
> > confusing. The argument is rarely used on module-level functions
>
> Since this only relates to the argument clinic, I assume this change
> doesn't get in the way of making module level functions real methods of
the
> module, does it?
Right, in that case (regardless of whether or not someone was using
argument clinic to do it), the callables would be declared as actual
methods of the custom module type rather than as module level functions.
Cheers,
Nick.
>
> Stefan
>
>
> ___
> 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] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.
On 11/05/2013 05:03 AM, vinay.sajip wrote: > http://hg.python.org/cpython/rev/5636366db039 > changeset: 86936:5636366db039 > branch: 3.3 > parent: 86933:2c191b0b5e7a > user:Vinay Sajip > date:Tue Nov 05 10:02:21 2013 + > summary: > Issue #18345: Added cookbook example illustrating handler customisation. > > files: > Doc/howto/logging-cookbook.rst | 135 + > 1 files changed, 135 insertions(+), 0 deletions(-) > > > diff --git a/Doc/howto/logging-cookbook.rst b/Doc/howto/logging-cookbook.rst > --- a/Doc/howto/logging-cookbook.rst > +++ b/Doc/howto/logging-cookbook.rst > @@ -1694,3 +1694,138 @@ > Note that the order of items might be different according to the version of > Python used. > > +.. currentmodule:: logging.config > + > +Customising handlers with :func:`dictConfig` > + I love all things British, but the python source code usually uses "customiz*" (341 instances) over "customis*" (19 instance, 8 of which are in logging). I realize "foolish consistency", and all that, but I think the documentation should all use the same conventions. I'd be happy to change the documentation. Eric. ___ 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] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.
On 11/05/2013 07:55 AM, Eric V. Smith wrote: > I love all things British, but the python source code usually uses > "customiz*" (341 instances) over "customis*" (19 instance, 8 of which > are in logging). > > I realize "foolish consistency", and all that, but I think the > documentation should all use the same conventions. I'd be happy to > change the documentation. http://bugs.python.org/issue19504 ___ 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] VAX NaN evaluations
I'm sorry to hear that - you might have been wasting your time (but
then, perhaps not).
We decided a while ago that the regular Python releases will not support
VAX/VMS any longer. So any code you write has zero chance of being
integrated into Python (the same holds for m68k code, BTW).
That said, you are free to maintain your own branch of Python. In that
branch, you can make whatever changes you consider necessary, but you
will be on your own.
Oh, it's definitely not wasting time. I seriously doubt I'd be asking
Python people to maintain patches upstream, because I seriously doubt we'd
have any to maintain - this is for NetBSD/VAX, not VMS. Running NetBSD on
VAX points out many instances where programmers make assumptions, so
everyone is helped when we address those assumptions.
From Steven D'Aprano:
Just to be clear, rather than dump core (which you suggested in a later
email), if you cannot support NANs on VAXen, you should modify float to
raise a ValueError exception. Pure Python code like float('nan') should
never dump core, it should raise:
ValueError: could not convert string to float: 'nan'
What Steven recommends makes a lot of sense, and if the Python folks don't
think it's worth adding a few lines to make NaN assignments optionally
raise an exception, we can keep the patches in NetBSD's pkgsrc.
So the next time I have a little time, I'll look through the code and see
if I can't find where that would be. And while I'm at it, I'll try to
learn a little Python ;)
Thanks,
John
___
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] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.
On 11/05/2013 04:55 AM, Eric V. Smith wrote: I love all things British, but the python source code usually uses "customiz*" (341 instances) over "customis*" (19 instance, 8 of which are in logging). I realize "foolish consistency", and all that, but I think the documentation should all use the same conventions. I'd be happy to change the documentation. Not using the same spelling for the same word would be, I think, a foolish inconsistency. (Curiously enough, although I'm USA, I keep using UK spellings. But not consistently. :/ ) -- ~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] PEP 454: tracemalloc (n-th version)
2013/11/3 Victor Stinner : > "n-th version": Sorry, I don't remember the version number of the PEP :-) > >http://www.python.org/dev/peps/pep-0454/ Charles-François doesn't like the magic Statistic.key attribute which may be a string, a tuple of 2 strings, or a tuple of (filename: str, lineno: str) tuples depending on key_type parameter of Snapshot.statistics(). So I replaced Statistic.key with Statistic.traceback which is always a traceback (tuple of (filename: str, lineno: str) tuples). I also renamed the key_type parameter of Snapshot.statistics() to "group_by". Victor ___ 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] Issue 19332: Guard against changing dict during iteration
http://bugs.python.org/issue19332
Summary:
--> d = {1: 'one'}
--> for k in d:
... d[k+1] = d[k] * k
...
Traceback (most recent call last):
File "", line 1, in
RuntimeError: dictionary changed size during iteration
--> for k in d:
... del d[k]
...
Traceback (most recent call last):
File "", line 1, in
RuntimeError: dictionary changed size during iteration
While the above two cases are covered, the following is not:
--> d = dict.fromkeys('abcd')
--> for i in d:
... print(i)
... d[i + 'x'] = None
... del d[i]
...
d
a
dx
dxx
ax
c
b
Which can yield pretty bizarre results and does not raise an exception.
There is a patch to fix this.
Raymond's first comment was:
"The decision to not monitor adding or removing keys was intentional. It is just not worth the cost in either time or
space."
Considering that the first two scenarios do raise exceptions that statement does not seem correct, at least not with
current code.
Later, Raymend rejected the patch with the comment:
"I disagree with adding such unimportant code to the critical path."
I understand we need to keep the critical path as fast as possible, and that it is a balancing act between completely
correct code and warnings in the docs.
What I'm hoping for is either someone to shed some light on what is the "unimportant" part, or perhaps some performance
measurements that would show there is no performance based reason to not have the patch added. (I can try to do the
performance part myself if necessary, I'm just not sure what all the steps are yet.)
--
~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] Issue 19332: Guard against changing dict during iteration
On 6 Nov 2013 15:02, "Ethan Furman" wrote:
>
> http://bugs.python.org/issue19332
>
> Summary:
>
> --> d = {1: 'one'}
> --> for k in d:
> ... d[k+1] = d[k] * k
> ...
> Traceback (most recent call last):
> File "", line 1, in
> RuntimeError: dictionary changed size during iteration
>
> --> for k in d:
> ... del d[k]
> ...
> Traceback (most recent call last):
> File "", line 1, in
> RuntimeError: dictionary changed size during iteration
>
>
> While the above two cases are covered, the following is not:
>
> --> d = dict.fromkeys('abcd')
> --> for i in d:
> ... print(i)
> ... d[i + 'x'] = None
> ... del d[i]
> ...
> d
> a
> dx
> dxx
> ax
> c
> b
>
> Which can yield pretty bizarre results and does not raise an exception.
>
> There is a patch to fix this.
>
> Raymond's first comment was:
>
> "The decision to not monitor adding or removing keys was intentional. It
is just not worth the cost in either time or space."
>
> Considering that the first two scenarios do raise exceptions that
statement does not seem correct, at least not with current code.
>
> Later, Raymend rejected the patch with the comment:
>
> "I disagree with adding such unimportant code to the critical path."
>
> I understand we need to keep the critical path as fast as possible, and
that it is a balancing act between completely correct code and warnings in
the docs.
>
> What I'm hoping for is either someone to shed some light on what is the
"unimportant" part,
The behaviour of mutating builtin containers while iterating over them is
formally undefined beyond "it won't segfault" (one of the few such
undefined behaviours in Python). The associated exceptions are thus
strictly "best effort given other constraints".
Since most loops are unlikely to add and remove exactly balanced numbers of
keys, and dict read and write performance impacts essentially all Python
code except that which only operates on function locals, only checking for
size changes between iteration steps is a nice way to get 99% of the
benefits without paying any of the costs.
>or perhaps some performance measurements that would show there is no
performance based reason to not have the patch added. (I can try to do the
performance part myself if necessary, I'm just not sure what all the steps
are yet.)
If the benchmark suite indicates there's no measurable speed penalty then
such a patch may be worth reconsidering. I'd be astonished if that was
actually the case, though - the lowest impact approach I can think of is to
check for live iterators when setting a dict entry, and that still has
non-trivial size and speed implications.
Cheers,
Nick.
>
> --
> ~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/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] Issue 19332: Guard against changing dict during iteration
On Nov 5, 2013 10:42 PM, "Nick Coghlan" wrote: > If the benchmark suite indicates there's no measurable speed penalty then such a patch may be worth reconsidering. I'd be astonished if that was actually the case, though - the lowest impact approach I can think of is to check for live iterators when setting a dict entry, and that still has non-trivial size and speed implications. If I remember right, I had to address something related in my C OrderedDict patch on issue #16991. I don't know if what I did there is applicable to dicts though. It's been a while since I worked on that patch. -eric ___ 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
