Re: [Python-Dev] What do PyAPI_FUNC & PyAPI_DATA mean?
> What do they mean, exactly? From the name I would expect that they are a > way of declaring a function or datum to be part of the API, but their > usage seems to be more to do with linkage. It means that they will be exported from the pythonXY.dll on Windows. In Windows DLLs, it's not sufficient to make a symbol global (non-static) to use it in an application, you also have to declare it as __declspec(dllexport), or list it in the linker definition file (which is not used today anymore). Likewise, to use a symbol from a DLL, you also need to declare it as __declspec(dllimport) in the using application. This will, in particular, arrange for a slot in the indirect-jump assembler section of the using DLL, so that the resulting executable will be position- independent (except for this procedure linkage section). As we have the same header files both for the implemenation and the usage, this macro tricky is necessary to sometimes say dllexport, sometimes dllimport. Even though it's strictly needed on Windows, and strictly only for API that we do want to expose, we apply it to all API that is public on Unix (i.e. all Py* API), in order to avoid API being available on Unix but not on Windows. Regards, Martin ___ 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] What do PyAPI_FUNC & PyAPI_DATA mean?
Am 23.04.2012 15:05, schrieb Kristján Valur Jónsson: > IMHO, we are _much_ too generous at applying this to almost whatever > gets exposed between .c files. I have created something called the > "restricted" api for our custom python27.dll where I use different > macros (PyAPI_RFUNC, pyAPI_RDATA) to mean that things aren't exported > for "restricted" builds. We use it to remove some of the easier > access points to the dll for hackers to exploit. > > Also, once declared exported this way, things become more bothersome > to remove again, since once could always argue that someone out there > is using these thigns. For this, PyAPI_FUNC doesn't really matter. A symbol that is listed in the header file is available on Unix even without such a declaration, so listing it in the public header file is already the step that makes it public, not specifying it as PyAPI_FUNC. I agree that too much API is public, but the right approach is to rename such API to _Py*, indicating to users that we don't want them to use it. For existing API, that's tricky; for new API, I think it should be private by default. See also PEP 384. Regards, Martin ___ 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] What do PyAPI_FUNC & PyAPI_DATA mean?
You know that I'm speaking of Windows, right? IMHO, we shouldn't put the PyAPI* stuff on functions unless they are actual API functions. I don't know how the export tables for ELF .so objects is generated, but it surely can't export _everything_. Anyway, marking stuff as part of the API makes sense, and marking functions as being part of the API makes no sense and is wasteful when they are not. We might even have something similar for the stable api. > -Original Message- > From: "Martin v. Löwis" [mailto:mar...@v.loewis.de] > Sent: 24. apríl 2012 07:31 > To: Kristján Valur Jónsson > Cc: Benjamin Peterson; Mark Shannon; Python Dev > Subject: Re: [Python-Dev] What do PyAPI_FUNC & PyAPI_DATA mean? > For this, PyAPI_FUNC doesn't really matter. A symbol that is listed in the > header file is available on Unix even without such a declaration, so listing > it in > the public header file is already the step that makes it public, not > specifying it > as PyAPI_FUNC. > > > I agree that too much API is public, but the right approach is to rename such > API to _Py*, indicating to users that we don't want them to use it. > For existing API, that's tricky; for new API, I think it should be private by > default. ___ 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] (time) PEP 418 glossary V2
Very nice! Two possible clarifications: On Tue, Apr 24, 2012 at 10:58 AM, Jim Jewett wrote: > Glossary > > Bias > > > Lack of accuracy that is systematically in one direction, as opposed to > random errors. When a clock is `Adjusted`_, durations overlapping the > adjustment will show a Bias. "Conversely, if the clock has experienced `Drift`_, its reports of `Absolute Time`_ will show Bias until the adjustment takes place." > Counter > --- > > A clock which increments each time a certain event occurs. A counter > is strictly monotonic in the mathematical sense, but does not meet > the typical definitions of Monotonic_ when used of a computer clock. > It can be used to generate a unique (and ordered) timestamp, but these > timestamps cannot be mapped to `Civil Time`_; Tick_ creation may well "mapped" -> "algorithmically mapped" > be bursty, with several advances in the same millisecond followed > by several days without any advance. > Duration_ measurements become less comparable, in return for providing > a more accurate `Absolute Time`_. ___ 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] cpython: Implement PEP 412: Key-sharing dictionaries (closes #13903)
Probably any benchmark involving a large amount of object instances with non-trivial dictionaries. Benchmarks should measure memory usage too, of course. Sadly that is not possible in standard cPython. Our 2.7 branch has extensive patching to allow custom memory allocators to be used (it even eliminates the explicit "malloc" calls used here and there in the code) and exposes some functions, such as sys.getpymalloced(), useful for memory benchmarking. Perhaps I should write about this on my blog. Updating the memory allocation macro layer in cPython for embedding is something I'd be inclined to contribute, but it will involve a large amount of bikeshedding, I'm sure :) Btw, this is of great interest to me at the moment, our Shanghai engineers are screaming at the memory waste incurred by dictionaries. A 10 item dictionary consumes 1/2k on 32 bits, did you know this? K > -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On > Behalf Of R. David Murray > Sent: 23. apríl 2012 21:56 > To: Antoine Pitrou > Cc: python-dev@python.org > Subject: Re: [Python-Dev] cpython: Implement PEP 412: Key-sharing > dictionaries (closes #13903) > > On Mon, 23 Apr 2012 22:22:18 +0200, Antoine Pitrou > wrote: > > On Mon, 23 Apr 2012 17:24:57 +0200 > > benjamin.peterson wrote: > > > http://hg.python.org/cpython/rev/6e5855854a2e > > > changeset: 76485:6e5855854a2e > > > user:Benjamin Peterson > > > date:Mon Apr 23 11:24:50 2012 -0400 > > > summary: > > > Implement PEP 412: Key-sharing dictionaries (closes #13903) > > > > I hope someone can measure the results of this change on real-world > > code. Benchmark results with http://hg.python.org/benchmarks/ are not > > overly promising. > > I'm pretty sure that anything heavily using sqlalchemy will benefit, so that > would be a good place to look for a real-world benchmark. > > --David > ___ > 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/kristjan%40ccpgames.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] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
> Here is a simplified version of the first draft of the PEP 418. The > full version can be read online. > http://www.python.org/dev/peps/pep-0418/ Thanks to everyone who helped me to work on this PEP! I integrated last comments. There is no more open question. (Or did I miss something?) I didn't know that it would be so hard to add a such simple function as time.monotonic()!? Victor ___ 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] What do PyAPI_FUNC & PyAPI_DATA mean?
Aha, so that is the rationale. Because the export table on unix is so generous, we force ourselves to be generous on windows too? I did some unix programming back in the day. IRIX, actually (a Sys V derivative). I'm pretty sure we had to explicitly specify our .so exports. But I might be mistaken. K > -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On > Behalf Of "Martin v. Löwis" > Sent: 24. apríl 2012 07:28 > To: Mark Shannon > Cc: Python Dev > Subject: Re: [Python-Dev] What do PyAPI_FUNC & PyAPI_DATA mean? > Even though it's strictly needed on Windows, and strictly only for API that we > do want to expose, we apply it to all API that is public on Unix (i.e. all Py* > API), in order to avoid API being available on Unix but not on Windows. ___ 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] (time) PEP 418 glossary V2
> Monotonic > - > > This is a particularly tricky term, as there are several subtly > incompatible definitions in use. Is it a definition for the glossary? > C++ followed the mathematical > definition, so that a monotonic clock only promises not to go > backwards. The "C++ Timeout Specification" doesn't have any monotonic anymore. It has a steady_clock, but it's something different. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.monotonic > In practice, that is not sufficient to be useful, and no > Operating System provides such a weak guarantee. Most discussions > of a "Monotonic *Clock*" will also assume several additional > guarantees, some of which are explicitly required by the POSIX > specification. What do you mean for POSIX? The definition of CLOCK_MONOTONIC by the POSIX specification is: "The identifier for the system-wide monotonic clock, which is defined as a clock whose value cannot be set via clock_settime() and which cannot have backward clock jumps. The maximum possible clock jump shall be implementation-defined." http://pubs.opengroup.org/onlinepubs/95399/basedefs/time.h.html time.monotonic() of the PEP 418 gives the same guarantee (cannot go backward, cannot be set), except for "system-wide" (Python cannot give this guarantee because of Windows older than Vista). > The tradeoffs > often include lack of a defined Epoch_ or mapping to `Civil Time`_, I don't know any monotonic with a defined epoch or mappable to the civil time. > and being more expensive (in `Latency`_, power usage, or duration spent > within calls to the clock itself) to use. CLOCK_MONOTONIC and CLOCK_REALTIME have the same performances on Linux and FreeBSD. Why would a monotonic clock be more expensive? > For example, the clock may > represent (a constant multiplied by) ticks of a specific quartz timer > on a specific CPU core, and calls would therefore require > synchronization between cores. I don't think that synchronizing a counter between CPU cores is something expensive. See the following tables for details: http://www.python.org/dev/peps/pep-0418/#performance CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource and so have the same latency depending on the hardware. Victor ___ 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] cpython: Implement PEP 412: Key-sharing dictionaries (closes #13903)
On Tue, 24 Apr 2012 10:24:16 + Kristján Valur Jónsson wrote: > > Btw, this is of great interest to me at the moment, our Shanghai engineers > are screaming at the > memory waste incurred by dictionaries. A 10 item dictionary consumes 1/2k on > 32 bits, did you > know this? The sparseness of hash tables is a well-known time/space tradeoff. See e.g. http://bugs.python.org/issue10408 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] (time) PEP 418 glossary V2
> Precision > - > > This is another tricky term, This is a good reason why it is no more used in the PEP :-) > Note that "precision" as reported by the clock itself may use yet > another definition, and may differ between clocks. Some C function provides the frequency of the clock (and so its resolution), or directly the resolution, but I don't know any function providing the precision. I thought that clock_getres() is the precision, but I was wrong. clock_getres() is really the resolution announced by the OS, even if the OS may be pessimistic (and so wrong, ex: OpenBSD and Solaris). But Python should not try to workaround OS "bugs". Victor ___ 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] Daily reference leaks (8dbcedfd13f8): sum=15528
On Tue, 24 Apr 2012 05:36:41 +0200 solip...@pitrou.net wrote: > results for 8dbcedfd13f8 on branch "default" > > > test_itertools leaked [44, 44, 44] references, sum=132 > test_robotparser leaked [103, 103, 103] references, sum=309 > test_ssl leaked [103, 103, 103] references, sum=309 > test_tempfile leaked [2, 2, 2] references, sum=6 > test_urllib leaked [103, 103, 103] references, sum=309 > test_urllib2 leaked [3208, 3208, 3208] references, sum=9624 > test_urllib2_localnet leaked [1078, 1078, 1078] references, sum=3234 > test_urllib2net leaked [432, 432, 432] references, sum=1296 > test_urllibnet leaked [103, 103, 103] references, sum=309 These seem to have been introduced by changeset 6e5855854a2e: “Implement PEP 412: Key-sharing dictionaries (closes #13903)”. 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] Daily reference leaks (8dbcedfd13f8): sum=15528
Antoine Pitrou wrote: On Tue, 24 Apr 2012 05:36:41 +0200 solip...@pitrou.net wrote: results for 8dbcedfd13f8 on branch "default" test_itertools leaked [44, 44, 44] references, sum=132 test_robotparser leaked [103, 103, 103] references, sum=309 test_ssl leaked [103, 103, 103] references, sum=309 test_tempfile leaked [2, 2, 2] references, sum=6 test_urllib leaked [103, 103, 103] references, sum=309 test_urllib2 leaked [3208, 3208, 3208] references, sum=9624 test_urllib2_localnet leaked [1078, 1078, 1078] references, sum=3234 test_urllib2net leaked [432, 432, 432] references, sum=1296 test_urllibnet leaked [103, 103, 103] references, sum=309 These seem to have been introduced by changeset 6e5855854a2e: “Implement PEP 412: Key-sharing dictionaries (closes #13903)”. I'm investigating at the moment. Cheers, Mark. ___ 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] cpython: Implement PEP 412: Key-sharing dictionaries (closes #13903)
On Tue, Apr 24, 2012 at 8:24 PM, Kristján Valur Jónsson wrote: > Perhaps I should write about this on my blog. Updating the memory allocation > macro layer in > cPython for embedding is something I'd be inclined to contribute, but it will > involve a large amount > of bikeshedding, I'm sure :) Trawl the tracker before you do - I'm pretty sure there's a patch (from the Nokia S60 port, IIRC) that adds a couple of macro definitions so that platform ports and embedding applications can intercept malloc() and free() calls. It would be way out of date by now, but I seem to recall thinking it looked reasonable at a quick glance. 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] cpython (2.7): Reorder the entries to put the type specific technique last.
On Tue, 24 Apr 2012 06:27:07 +0200 raymond.hettinger wrote: > http://hg.python.org/cpython/rev/e2a3260f1718 > changeset: 76513:e2a3260f1718 > branch: 2.7 > parent: 76480:db26c4daecbb > user:Raymond Hettinger > date:Mon Apr 23 21:24:15 2012 -0700 > summary: > Reorder the entries to put the type specific technique last. Do you intend to port all your doc changes to 3.2 and 3.x? 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] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)
I'm not happy with this fix.
Admittedly code like:
class S(str):
__getattr__ = str.__add__
s = S('a')
print(S.b)
is a little weird.
But I think it should work (ie print 'ab') properly.
This works without the patch.
class S(str):
__getattribute__ = str.__add__
s = S('a')
print(S.b)
(Prints 'ab')
Also "slot wrapper" is a low-level implementation detail and
shouldn't impact the language semantics.
dict.__getitem__ is a slot wrapper; dict.__getitem__ is not.
str.__getitem__ is a slot wrapper; list.__getitem__ is not.
If any of these change then the semantics of the language changes.
Cheers,
Mark
benjamin.peterson wrote:
http://hg.python.org/cpython/rev/971865f12377
changeset: 76518:971865f12377
branch: 3.2
parent: 76506:f7b002e5cac7
user:Benjamin Peterson
date:Tue Apr 24 11:06:25 2012 -0400
summary:
don't use a slot wrapper from a different special method (closes #14658)
This also alters the fix to #11603. Specifically, setting __repr__ to
object.__str__ now raises a recursion RuntimeError when str() or repr() is
called instead of silently bypassing the recursion. I believe this behavior is
more correct.
files:
Lib/test/test_descr.py | 10 +-
Misc/NEWS | 6 ++
Objects/typeobject.c | 5 +++--
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Lib/test/test_descr.py b/Lib/test/test_descr.py
--- a/Lib/test/test_descr.py
+++ b/Lib/test/test_descr.py
@@ -4430,7 +4430,15 @@
pass
Foo.__repr__ = Foo.__str__
foo = Foo()
-str(foo)
+self.assertRaises(RuntimeError, str, foo)
+self.assertRaises(RuntimeError, repr, foo)
+
+def test_mixing_slot_wrappers(self):
+class X(dict):
+__setattr__ = dict.__setitem__
+x = X()
+x.y = 42
+self.assertEqual(x["y"], 42)
def test_cycle_through_dict(self):
# See bug #1469629
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,12 @@
Core and Builtins
-
+- Issue #11603 (again): Setting __repr__ to __str__ now raises a RuntimeError
+ when repr() or str() is called on such an object.
+
+- Issue #14658: Fix binding a special method to a builtin implementation of a
+ special method with a different name.
+
- Issue #14630: Fix a memory access bug for instances of a subclass of int
with value 0.
diff --git a/Objects/typeobject.c b/Objects/typeobject.c
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -2928,7 +2928,7 @@
unaryfunc f;
f = Py_TYPE(self)->tp_repr;
-if (f == NULL || f == object_str)
+if (f == NULL)
f = object_repr;
return f(self);
}
@@ -5757,7 +5757,8 @@
}
continue;
}
-if (Py_TYPE(descr) == &PyWrapperDescr_Type) {
+if (Py_TYPE(descr) == &PyWrapperDescr_Type &&
+((PyWrapperDescrObject *)descr)->d_base->name_strobj ==
p->name_strobj) {
void **tptr = resolve_slotdups(type, p->name_strobj);
if (tptr == NULL || tptr == ptr)
generic = p->function;
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
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] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)
2012/4/24 Mark Shannon :
> I'm not happy with this fix.
It's not perfect, but it's an improvement.
>
> Admittedly code like:
>
> class S(str):
> __getattr__ = str.__add__
> s = S('a')
> print(S.b)
>
> is a little weird.
> But I think it should work (ie print 'ab') properly.
>
> This works without the patch.
>
> class S(str):
> __getattribute__ = str.__add__
> s = S('a')
> print(S.b)
Does it?
$ cat > x.py
class S(str):
__getattribute__ = str.__add__
s = S('a')
print(S.b)
$ python3 x.py
Traceback (most recent call last):
File "x.py", line 4, in
print(S.b)
AttributeError: type object 'S' has no attribute 'b'
>
> (Prints 'ab')
>
> Also "slot wrapper" is a low-level implementation detail and
> shouldn't impact the language semantics.
>
> dict.__getitem__ is a slot wrapper; dict.__getitem__ is not.
> str.__getitem__ is a slot wrapper; list.__getitem__ is not.
> If any of these change then the semantics of the language changes.
--
Regards,
Benjamin
___
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] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)
Benjamin Peterson wrote:
2012/4/24 Mark Shannon :
I'm not happy with this fix.
It's not perfect, but it's an improvement.
Admittedly code like:
class S(str):
__getattr__ = str.__add__
s = S('a')
print(S.b)
My typo, should be:
print(s.b)
(Instance not class)
This doesn't work.
is a little weird.
But I think it should work (ie print 'ab') properly.
This works without the patch.
class S(str):
__getattribute__ = str.__add__
s = S('a')
print(S.b)
Same typo,
this does work (with correct spelling :) )
Does it?
$ cat > x.py
class S(str):
__getattribute__ = str.__add__
s = S('a')
print(S.b)
$ python3 x.py
Traceback (most recent call last):
File "x.py", line 4, in
print(S.b)
AttributeError: type object 'S' has no attribute 'b'
(Prints 'ab')
Also "slot wrapper" is a low-level implementation detail and
shouldn't impact the language semantics.
dict.__getitem__ is a slot wrapper; dict.__getitem__ is not.
str.__getitem__ is a slot wrapper; list.__getitem__ is not.
If any of these change then the semantics of the language changes.
___
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] (time) PEP 418 glossary V2
On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner wrote: >> Monotonic >> - >> This is a particularly tricky term, as there are several subtly >> incompatible definitions in use. > Is it a definition for the glossary? One use case for a PEP is that someone who does *not* have a background in the area wants to start learning about it. Even excluding the general service of education, these people can be valuable contributors, because they have a fresh perspective. They will almost certainly waste some time retracing dead ends, but I would prefer it be out of a need to prove things to themselves, instead of just because they misunderstood. Given the amount of noise we already went through arguing over what "Monotonic" should mean, I think we have an obligation to provide these people with a heads-up, even if we don't end up using the term ourselves. And I think we *will* use the terms ourselves, if only as some of the raw os_clock_* choices. >> C++ followed the mathematical definition >> ... a monotonic clock only promises not to go backwards. >> ... additional guarantees, some ... required by the POSIX Confession: I based the above statements strictly on posts to python-dev, from people who seemed to have some experience caring about clock details. I did not find the relevant portions of either specification.[1] Every time I started to search, I got pulled back to other tasks, and the update was just delayed even longer. I still felt it was worth consolidating the state of the discussion. Anyone who feels confident in this domain is welcome to correct me, and encouraged to send replacement text. [1] Can I assume that Victor's links here are the relevant ones, or is someone aware of additional/more complete references for these specifications? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.monotonic http://pubs.opengroup.org/onlinepubs/95399/basedefs/time.h.html >> The tradeoffs often include lack of a defined Epoch_ >> or mapping to `Civil Time`_, > I don't know any monotonic with a defined epoch or > mappable to the civil time. The very basic "seconds (not even milliseconds) since the beginning of 1970" fits that definition, but doesn't seem to fit what most people mean by "Monotonic Clock". I'm still a little fuzzy on *why* it shouldn't count as a monotonic clock. Is it technically valid, but a lousy implementation because of insufficient precision or resolution? Is it because the functions used in practice (on a modern OS) to retrieve timestamps don't guarantee to ignore changes to the system clock? >> and being more expensive (in `Latency`_, power usage, or duration spent >> within calls to the clock itself) to use. > CLOCK_MONOTONIC and CLOCK_REALTIME have the same performances on Linux > and FreeBSD. Why would a monotonic clock be more expensive? >> For example, the clock may >> represent (a constant multiplied by) ticks of a specific quartz timer >> on a specific CPU core, and calls would therefore require >> synchronization between cores. > I don't think that synchronizing a counter between CPU cores is > something expensive. See the following tables for details: > http://www.python.org/dev/peps/pep-0418/#performance Synchronization is always relatively expensive. How expensive depends on a lot of things decides before python was installed. Looking at the first table there (Linux 3.3 with Intel Core i7-2600 at 3.40GHz (8 cores)), CLOCK_MONOTONIC can be hundreds of times slower than time(), and over 50 times slower than CLOCK_MONOTONIC_COARSE. I would assume that CLOCK_MONOTONIC_COARSE meets the technical requirements for a monotonic clock, but does less well at meeting the actual expectations for some combination of (precision/stability/resolution). > CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource > and so have the same latency depending on the hardware. Is this a rule of thumb or a requirement of some standard? Does that fact that Windows, Mac OS X, and GNU/Hurd don't support CLOCK_MONOTONIC indicate that there is a (perhaps informal?) specification that none of their clocks meet, or does it only indicate that they didn't like the name? -jJ ___ 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] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)
Mark Shannon wrote:
Benjamin Peterson wrote:
2012/4/24 Mark Shannon :
I'm not happy with this fix.
It's not perfect, but it's an improvement.
Admittedly code like:
class S(str):
__getattr__ = str.__add__
s = S('a')
print(S.b)
My typo, should be:
print(s.b)
(Instance not class)
is a little weird.
But I think it should work (ie print 'ab') properly.
I can easily believe I'm missing something, but here are the results
with the patch in place:
{'x': 42} 42
{'x': 42} 42
ab
and here's the code:
class Foo1(dict):
def __getattr__(self, key): return self[key]
def __setattr__(self, key, value): self[key] = value
class Foo2(dict):
__getattr__ = dict.__getitem__
__setattr__ = dict.__setitem__
o1 = Foo1()
o1.x = 42
print(o1, o1.x)
o2 = Foo2()
o2.x = 42
print(o2, o2.x)
class S(str):
__getattr__ = str.__add__
s = S('a')
print(s.b)
~Ethan~
___
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] (time) PEP 418 glossary V2
>> I don't know any monotonic with a defined epoch or >> mappable to the civil time. > > The very basic "seconds (not even milliseconds) since the beginning of > 1970" fits that definition, but doesn't seem to fit what most people > mean by "Monotonic Clock". > > I'm still a little fuzzy on *why* it shouldn't count as a monotonic > clock. Is it technically valid, but a lousy implementation because of > insufficient precision or resolution? Is it because the functions > used in practice (on a modern OS) to retrieve timestamps don't > guarantee to ignore changes to the system clock? You mean the time() function? It is the system clock and the system clock is not monotonic because it can jump backward. It is also affected when... the system clock is changed :-) > Looking at the first table there (Linux 3.3 with Intel Core i7-2600 at > 3.40GHz (8 cores)), CLOCK_MONOTONIC can be hundreds of times slower > than time(), and over 50 times slower than CLOCK_MONOTONIC_COARSE. I > would assume that CLOCK_MONOTONIC_COARSE meets the technical > requirements for a monotonic clock, but does less well at meeting the > actual expectations for some combination of > (precision/stability/resolution). I chose CLOCK_MONOTONIC instead of CLOCK_MONOTONIC_COARSE because I bet that most people prefer a clock with an higher precision over a faster clock. When the issue #14555 (Add more clock identifiers) will be done, you will be able to call time.clock_gettime(time.CLOCK_MONOTONIC_COARSE) in Python if you need a faster monotonic clock. >> CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource >> and so have the same latency depending on the hardware. > > Is this a rule of thumb or a requirement of some standard? It is how these clocks are implemented on Linux. I don't know how they are implemented on other OSes. It was just to say that their performance should be *very close* on Linux. > Does that fact that Windows, Mac OS X, and GNU/Hurd don't support > CLOCK_MONOTONIC indicate that there is a (perhaps informal?) > specification that none of their clocks meet, or does it only indicate > that they didn't like the name? CLOCK_MONOTONIC requires the clock_gettime() function: clock_gettime() is not available on Windows nor Mac OS X. For Hurd, see: http://www.gnu.org/software/hurd/open_issues/clock_gettime.html The PEP 418 uses other monotonic clocks for Windows and Mac OS X, but GNU/Hurd is the only OS not supporting the new time.monotonic() function. Victor ___ 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] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py
On Thu, Apr 19, 2012 at 18:56, eric.smith wrote: > +Note that an ImportError will no longer be raised for a directory > +lacking an ``__init__.py`` file. Such a directory will now be imported > +as a namespace package, whereas in prior Python versions an > +ImportError would be raised. Given that there is no way to modify the __path__ of a namespace package (short of restarting python?), *should* it be an error if there is exactly one directory? Or is that just a case of "other tools out there, didn't happen to install them"? -jJ ___ 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] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py
> On Thu, Apr 19, 2012 at 18:56, eric.smith wrote: > >> +Note that an ImportError will no longer be raised for a directory >> +lacking an ``__init__.py`` file. Such a directory will now be imported >> +as a namespace package, whereas in prior Python versions an >> +ImportError would be raised. > > Given that there is no way to modify the __path__ of a namespace > package (short of restarting python?), *should* it be an error if > there is exactly one directory? > > Or is that just a case of "other tools out there, didn't happen to > install them"? Right. If I just install zope.interfaces and no other zope packages, that shouldn't be an error. Eric. ___ 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
On 19.04.2012 03:36, ezio.melotti wrote: > http://hg.python.org/cpython/rev/36c901fcfcda > changeset: 76413:36c901fcfcda > branch: 2.7 > user:Ezio Melotti > date:Wed Apr 18 19:08:41 2012 -0600 > summary: > #14538: HTMLParser can now parse correctly start tags that contain a bare /. > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -50,6 +50,9 @@ > Library > --- > > +- Issue #14538: HTMLParser can now parse correctly start tags that contain > + a bare '/'. > + I think that's misleading: there's no way to "correctly" parse malformed HTML. 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] What do PyAPI_FUNC & PyAPI_DATA mean?
Quoting Kristján Valur Jónsson : You know that I'm speaking of Windows, right? Yes, but this may only be valid for CCP; for CPython, we certainly have to consider Unix as well. IMHO, we shouldn't put the PyAPI* stuff on functions unless they are actual API functions. I don't know how the export tables for ELF .so objects is generated, but it surely can't export _everything_. It certainly does. Any global symbol in an ELF shared library gets exported. There are recent (10 years or so) ways to restrict this, by declaring symbols as hidden in the object file, but exporting everything is the default that Python uses. Anyway, marking stuff as part of the API makes sense, and marking functions as being part of the API makes no sense and is wasteful when they are not. There are cases where it's necessary: when an extension module uses a function that is not in the API. We might even have something similar for the stable api. I don't understand. Everything in the stable api is part of the API, and thus needs to be exported from the Python DLL. Regards, Martin ___ 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] What do PyAPI_FUNC & PyAPI_DATA mean?
Quoting Kristján Valur Jónsson : Aha, so that is the rationale. Because the export table on unix is so generous, we force ourselves to be generous on windows too? Yes. If the code compiles and links on Unix, it shall also compile and link on Windows. I did some unix programming back in the day. IRIX, actually (a Sys V derivative). I'm pretty sure we had to explicitly specify our .so exports. But I might be mistaken. Maybe on IRIX, probably in a way that predates ELF. In the old days, on Linux, you had to globally request address space from Linus Torvalds for shared libraries. These days are long gone. ELF shared libraries are designed to give the same experience (roughly) as static libraries, wrt. source compatibility. Regards, Martin ___ 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] Repeated hangs during "make test"
CPython 3.3.0a2 (default, Apr 24 2012, 10:47:03) [GCC 4.4.5] Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.4 little-endian Ran "make test". Hung during test_socket. Used CNTL-C to exit the test. test_ssl failed. Ran "./python -m test -v test_ssl". Test ok. Ran "./python -m test -v test_socket" which was ok. Ran "make test" again. Hung during test_concurrent_futures. Used CNTL-C to exit test_concurrent_futures. test_ssl failed. Ran "./python -m test -v test_ssl". Test ok. Ran "make test" a third time. Hung during test_io. Used CNTL-C to exit test_io. test_ssl failed. Ran "./python -m test -v test_ssl". Test ok. Did it again. Same behavior except the hang is in test_buffer. And again for test_httpservers. What is going on? ___ 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] cpython: Implement PEP 412: Key-sharing dictionaries (closes #13903)
Benchmarks should measure memory usage too, of course. Sadly that is not possible in standard cPython. It's actually very easy in standard CPython, using sys.getsizeof. Btw, this is of great interest to me at the moment, our Shanghai engineers are screaming at the memory waste incurred by dictionaries. A 10 item dictionary consumes 1/2k on 32 bits, did you know this? I did. In Python 3.3, this now goes down to 248 bytes (32 bits). Regards, Martin ___ 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
2012/4/24 Georg Brandl : > On 19.04.2012 03:36, ezio.melotti wrote: >> http://hg.python.org/cpython/rev/36c901fcfcda >> changeset: 76413:36c901fcfcda >> branch: 2.7 >> user: Ezio Melotti >> date: Wed Apr 18 19:08:41 2012 -0600 >> summary: >> #14538: HTMLParser can now parse correctly start tags that contain a bare >> /. > >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -50,6 +50,9 @@ >> Library >> --- >> >> +- Issue #14538: HTMLParser can now parse correctly start tags that contain >> + a bare '/'. >> + > > I think that's misleading: there's no way to "correctly" parse malformed HTML. There is in the since that you can follow the HTML5 algorithm, which can "parse" any junk you throw at it. -- Regards, Benjamin ___ 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
On Tue, Apr 24, 2012 at 2:34 PM, Benjamin Peterson wrote: > There is in the since that you can follow the HTML5 algorithm, which > can "parse" any junk you throw at it. This whole can of worms is why I gave up on HTML years ago (well, one reason among many). There are markup languages, and there's soup. -Fred -- Fred L. Drake, Jr. "A person who won't read has no advantage over one who can't read." --Samuel Langhorne Clemens ___ 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
On 24.04.2012 20:34, Benjamin Peterson wrote: > 2012/4/24 Georg Brandl : >> On 19.04.2012 03:36, ezio.melotti wrote: >>> http://hg.python.org/cpython/rev/36c901fcfcda >>> changeset: 76413:36c901fcfcda >>> branch: 2.7 >>> user:Ezio Melotti >>> date:Wed Apr 18 19:08:41 2012 -0600 >>> summary: >>> #14538: HTMLParser can now parse correctly start tags that contain a bare >>> /. >> >>> diff --git a/Misc/NEWS b/Misc/NEWS >>> --- a/Misc/NEWS >>> +++ b/Misc/NEWS >>> @@ -50,6 +50,9 @@ >>> Library >>> --- >>> >>> +- Issue #14538: HTMLParser can now parse correctly start tags that contain >>> + a bare '/'. >>> + >> >> I think that's misleading: there's no way to "correctly" parse malformed >> HTML. > > There is in the since that you can follow the HTML5 algorithm, which > can "parse" any junk you throw at it. Ah, good. Then I hope we are following the algorithm here (and are slowly coming to use it for htmllib in general). 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
2012/4/24 Benjamin Peterson : > There is in the since This is confusing, since I meant "sense". -- Regards, Benjamin ___ 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] cpython: Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add some
On Tue, 24 Apr 2012 21:00:49 +0200 jesus.cea wrote: > http://hg.python.org/cpython/rev/2023f48b32b6 > changeset: 76537:2023f48b32b6 > user:Jesus Cea > date:Tue Apr 24 20:59:17 2012 +0200 > summary: > Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add > some Solaris constants too) Could you please add a Misc/NEWS entry for all this? Thank you 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
Le 24/04/2012 15:02, Georg Brandl a écrit : On 24.04.2012 20:34, Benjamin Peterson wrote: 2012/4/24 Georg Brandl: I think that's misleading: there's no way to "correctly" parse malformed HTML. There is in the since that you can follow the HTML5 algorithm, which can "parse" any junk you throw at it. Ah, good. Then I hope we are following the algorithm here (and are slowly coming to use it for htmllib in general). Yes, Ezio’s commits on html.parser/HTMLParser in the last months have been following the HTML5 spec. Ezio, RDM and I have had some discussion about that on some bug reports, IRC and private mail and reached the agreement to do the useful thing, that is follow HTML5 and not pretend that the stdlib parser is strict or validating. Ezio was thinking about a blog.python.org post to advertise this. Regards ___ 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
On Tue, Apr 24, 2012 at 14:34, Éric Araujo wrote: > Le 24/04/2012 15:02, Georg Brandl a écrit : >> >> On 24.04.2012 20:34, Benjamin Peterson wrote: >>> >>> 2012/4/24 Georg Brandl: I think that's misleading: there's no way to "correctly" parse malformed HTML. >>> >>> There is in the since that you can follow the HTML5 algorithm, which >>> can "parse" any junk you throw at it. >> >> Ah, good. Then I hope we are following the algorithm here (and are slowly >> coming to use it for htmllib in general). > > > Yes, Ezio’s commits on html.parser/HTMLParser in the last months have been > following the HTML5 spec. Ezio, RDM and I have had some discussion about > that on some bug reports, IRC and private mail and reached the agreement to > do the useful thing, that is follow HTML5 and not pretend that the stdlib > parser is strict or validating. > > Ezio was thinking about a blog.python.org post to advertise this. Please do this, and I welcome anyone else who wants to write about their work on the blog to do so. Contact me for info. ___ 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] cpython: Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add some
> jesus.cea wrote: >> http://hg.python.org/cpython/rev/2023f48b32b6 >> changeset: 76537:2023f48b32b6 >> user:Jesus Cea >> date:Tue Apr 24 20:59:17 2012 +0200 >> summary: >> Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I >> add some Solaris constants too) > > Could you please add a Misc/NEWS entry for all this? I also tend to always update Misc/ACKS too, even for "trivial" patches. ___ 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] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)
Benjamin Peterson wrote: 2012/4/24 Mark Shannon : I'm not happy with this fix. It's not perfect, but it's an improvement. Actually, I think it is probably correct. I've been trying to break it by assigning various unusual objects to special attributes and it seems OK so far. I don't really trust all that slot-wrapper stuff, but rewriting is a lot of work and would introduce new errors, so I'll just leave it at that. [snip] Cheers, Mark. ___ 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] [Python-checkins] cpython: Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add some
2012/4/24 jesus.cea : > http://hg.python.org/cpython/rev/2023f48b32b6 > changeset: 76537:2023f48b32b6 > user: Jesus Cea > date: Tue Apr 24 20:59:17 2012 +0200 > summary: > Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add > some Solaris constants too) Don't you want to document these new constants in Doc/library/os.rst? Victor ___ 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] Repeated hangs during "make test"
2012/4/24 Edward C. Jones : > CPython 3.3.0a2 (default, Apr 24 2012, 10:47:03) [GCC 4.4.5] > Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.4 little-endian > > Ran "make test". Hung during test_socket. Used CNTL-C to exit the test. Can you investigate what is blocked in the test? Can you at least provide a traceback? You may try the timeout option of -m test. Example: $ ./python -m test --timeout=60 # seconds > What is going on? I'm unable to reproduce the bug, so I cannot help you :-( Victor ___ 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] Repeated hangs during "make test"
On Tue, 24 Apr 2012 12:05:46 -0400 "Edward C. Jones" wrote: > CPython 3.3.0a2 (default, Apr 24 2012, 10:47:03) [GCC 4.4.5] > Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.4 little-endian > > Ran "make test". Hung during test_socket. Used CNTL-C to exit the test. > test_ssl failed. Ran "./python -m test -v test_ssl". Test ok. Ran > "./python -m test -v test_socket" which was ok. > > Ran "make test" again. Hung during test_concurrent_futures. Used CNTL-C to > exit test_concurrent_futures. test_ssl failed. Ran > "./python -m test -v test_ssl". Test ok. > > Ran "make test" a third time. Hung during test_io. Used CNTL-C to > exit test_io. test_ssl failed. Ran "./python -m test -v test_ssl". > Test ok. Remember to pass "-uall" when running tests with "./python -m test [something]". Otherwise some test cases get skipped. 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
[Python-Dev] netiquette on py-dev
Okay, advice please. When responding to posts, should the poster to whom I am responding be listed as well as python-dev, or should my responses just go to python-dev? I see both ways occuring, and am not sure if one or the other is preferred. As a reference point, on python-list I almost never have the previous respondent's email in the CC list. ~Ethan~ ___ 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] netiquette on py-dev
On Tue, 24 Apr 2012 13:46:51 -0700 Ethan Furman wrote: > Okay, advice please. > > When responding to posts, should the poster to whom I am responding be > listed as well as python-dev, or should my responses just go to python-dev? I prefer responses to python-dev only myself; I am always a bit annoyed to get some responses in (half-)private, since that's just duplicate with me reading the list with gmane. 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] netiquette on py-dev
On Tue, Apr 24, 2012 at 01:46:51PM -0700, Ethan Furman wrote: > When responding to posts, should the poster to whom I am responding > be listed as well as python-dev, or should my responses just go to > python-dev? I reply to list only, except when I want extra attention (e.g. when I direct people to comp.lang.python). My MUA has 3 reply commands - reply to the author, group reply (reply to all) and list reply (mailing lists are configured) so it's easy for me to choose which way I'm replying. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] netiquette on py-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2012 04:46 PM, Ethan Furman wrote: > Okay, advice please. > > When responding to posts, should the poster to whom I am responding be > listed as well as python-dev, or should my responses just go to > python-dev? > > I see both ways occuring, and am not sure if one or the other is > preferred. > > As a reference point, on python-list I almost never have the previous > respondent's email in the CC list. I prefer not to be CC'ed, as I am gonna read the message on the list anyway. I almost never CC the author on a list post, unless specifically asked (e.g., where the list is not open-subscription, as in a security response list). I occasionally CC a third user whom I know is subscribed, intending that as a "poke" / escalation (they might miss or defer replying to the message). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+XJ34ACgkQ+gerLs4ltQ4zogCeJeqS1eHMJ17FETzUkIQgkw8B hQkAoNmDcp1WLLAMSqFr9fGDXFtAjO3W =hKRe -END PGP SIGNATURE- ___ 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] netiquette on py-dev
Ethan Furman writes: > When responding to posts, should the poster to whom I am responding be > listed as well as python-dev, or should my responses just go to > python-dev? IMO, the poster to whom you are responding should expect to read your response in the same forum where their message appeared. So, no need to send them another copy individually. -- \ “There is something wonderful in seeing a wrong-headed majority | `\ assailed by truth.” —John Kenneth Galbraith, 1989-07-28 | _o__) | Ben Finney ___ 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] (time) PEP 418 glossary V2
On Wed, Apr 25, 2012 at 1:19 AM, Jim Jewett wrote: > I'm still a little fuzzy on *why* it shouldn't count as a monotonic > clock. So are the people who say it shouldn't count (unless you're speaking of the specific implementation on Unix systems, which can go backward if the admin or NTP decides it should be so). I think they are in general mistaking their use case for a general specification, that's all. Even Glyph cited "what other people seem to think" in supporting the usage where "monotonic" implies "high quality" in some informal sense, although he does have a spec for what high quality means, and AIUI an API for it in Twisted. I think we should just accept that "monotonic" is in more or less common use as a synonym for "high quality", and warn *our* users that the implementers of such clocks may be working to a different spec. I think the revised glossary's description of "monotonic" does that pretty well. ___ 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] netiquette on py-dev
On Wed, Apr 25, 2012 at 5:46 AM, Ethan Furman wrote: > When responding to posts, should the poster to whom I am responding be > listed as well as python-dev, or should my responses just go to python-dev? > > I see both ways occuring, and am not sure if one or the other is preferred. I don't know of any webmail implementations that provide reply-to-list, so a lot of us end up using reply-to-all. Cleaning up the headers requires at least deleting the To (which is where the author ends up), and perhaps moving the list from Cc to To (to make it pretty, I don't think a nonempty To is actually required by the RFC). Especially on a mobile device this is a PITA. So in most cases I suppose that the duplicate going to the author is just an issue of "energy conservation" on the part of the responder. Note that people who are really annoyed by the duplicates can set their Mailman accounts to no-dupes, and Mailman won't send the post to that person. (This has its disadvantages in principle -- no List-* headers and other list-specific info -- and in implementation -- at best Mailman can change all your lists at one site, so you need to do this on every site you subscribe to. But it's an option.) This won't work for people who read on Gmane, of course, since they don't own the subscription where they're reading the list. ___ 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] netiquette on py-dev
On Wed, Apr 25, 2012 at 1:44 PM, Stephen J. Turnbull wrote: > I don't know of any webmail implementations that provide > reply-to-list, so a lot of us end up using reply-to-all. Cleaning up > the headers requires at least deleting the To (which is where the > author ends up), and perhaps moving the list from Cc to To (to make it > pretty, I don't think a nonempty To is actually required by the RFC). > Especially on a mobile device this is a PITA. I go the other way: hit Reply, and then replace the author's address with the list's. I'd much rather have a Reply List though. Unfortunately no decent webmail seems to have it, and I'm still looking for a decent non-web-mail client too. ChrisA ___ 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] netiquette on py-dev
On Wed, Apr 25, 2012 at 1:58 PM, Chris Angelico wrote: > On Wed, Apr 25, 2012 at 1:44 PM, Stephen J. Turnbull > wrote: >> I don't know of any webmail implementations that provide >> reply-to-list, so a lot of us end up using reply-to-all. Cleaning up >> the headers requires at least deleting the To (which is where the >> author ends up), and perhaps moving the list from Cc to To (to make it >> pretty, I don't think a nonempty To is actually required by the RFC). >> Especially on a mobile device this is a PITA. > > I go the other way: hit Reply, and then replace the author's address > with the list's. I'd much rather have a Reply List though. > Unfortunately no decent webmail seems to have it, and I'm still > looking for a decent non-web-mail client too. I used to do that, but switched to using Reply-All instead after sending too many unintentionally off-list replies. So yeah, the basic problem is mail clients that don't offer a "Reply-List" option, with the Gmail web client being a notable offender. 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] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py
On Wed, Apr 25, 2012 at 2:56 AM, Jim Jewett wrote: > On Thu, Apr 19, 2012 at 18:56, eric.smith wrote: > >> +Note that an ImportError will no longer be raised for a directory >> +lacking an ``__init__.py`` file. Such a directory will now be imported >> +as a namespace package, whereas in prior Python versions an >> +ImportError would be raised. > > Given that there is no way to modify the __path__ of a namespace > package (short of restarting python?), *should* it be an error if > there is exactly one directory? > > Or is that just a case of "other tools out there, didn't happen to > install them"? Or you installed all of them into the same directory (as distro packages are likely to do). Also, a namespace package __path__ is still just a list - quite amenable to modification after creation. The only thing we're not currently promising in PEP 420 is a programmatic interface to redo the scan. 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
