Re: [Python-Dev] windows file closing race condition?

[Nick Coghlan]

On 6 September 2013 15:50, Chris Withers  wrote:
> Hi All,
>
> Continuous testing is a wonderful thing when it comes to finding weird edge
> case problems, like this one:
>
> http://jenkins.simplistix.co.uk/job/testfixtures-tox/COMPONENTS=zc,PYTHON=3.3,label=windows/149/testReport/junit/testfixtures.tests.test_tempdirectory/TempDirectoryTests/test_check_all_tuple/
>
>   File
> "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\site-packages\testfixtures\tempdirectory.py",
> line 323, in __exit__
> self.cleanup()
>   File
> "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\site-packages\testfixtures\tempdirectory.py",
> line 78, in cleanup
> rmtree(self.path)
>   File
> "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py",
> line 460, in rmtree
> return _rmtree_unsafe(path, onerror)
>   File
> "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py",
> line 362, in _rmtree_unsafe
> _rmtree_unsafe(fullname, onerror)
>   File
> "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py",
> line 371, in _rmtree_unsafe
> onerror(os.rmdir, path, sys.exc_info())
>   File
> "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py",
> line 369, in _rmtree_unsafe
> os.rmdir(path)
> OSError: [WinError 145] The directory is not empty:
> 'c:\\users\\jenkins\\appdata\\local\\temp\\tmpkeg4d7\\a'
>
> I'm 99% certain my code is correct here, the only place I open files for
> writing in that directory is here:
>
> https://github.com/Simplistix/testfixtures/blob/master/testfixtures/tempdirectory.py#L275
>
> So, from my perspective, I'm either looking at a bug in shutil.rmtree (which
> would be trying to delete a directory before deleting its content or failing
> to delete a file but ignoring an error) or the file object, when being used
> as a context manager, going through __exit__ without closing the file and
> releasing the handle.
>
> This happens very infrequently, the OS is Windows 7 and the filesystem is
> NTFS, if that helps...
>
> Any ideas?

This feels a lot like an issue we were seeing on the Windows
buildbots, which we ended up working around in the test support
library: http://bugs.python.org/issue15496

That would be some awfully ugly code to upgrade from "hack in the test
support library" to "this is just how Python unlinks files on
Windows", though :P

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] windows file closing race condition?

[Chris Withers]

On 06/09/2013 07:10, Antoine Pitrou wrote:

This happens very infrequently, the OS is Windows 7 and the filesystem
is NTFS, if that helps...


It should help indeed:
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/07/10347136.aspx


The box in questions runs no AV software or indexing services...

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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] windows file closing race condition?

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > http://blogs.msdn.com/b/oldnewthing/archive/2012/09/07/10347136.aspx

That was worth it just for the comment from Australia!
___
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] windows file closing race condition?

[Tim Golden]

On 06/09/2013 08:14, Nick Coghlan wrote:
> On 6 September 2013 15:50, Chris Withers  wrote:
>> Continuous testing is a wonderful thing when it comes to finding weird edge
>> case problems, like this one:

[... snip ...]
>> os.rmdir(path)
>> OSError: [WinError 145] The directory is not empty:
>> 'c:\\users\\jenkins\\appdata\\local\\temp\\tmpkeg4d7\\a'

> This feels a lot like an issue we were seeing on the Windows
> buildbots, which we ended up working around in the test support
> library: http://bugs.python.org/issue15496
> 
> That would be some awfully ugly code to upgrade from "hack in the test
> support library" to "this is just how Python unlinks files on
> Windows", though :P

I think that any kind of delay-retry loop falls squarely within the
remit of the calling application, not core Python. This isn't a problem
of Python's making: IIUC, you would see the same effect if you used any
other
language or simply deleted the folder from within Explorer. (I don't
know whether Explorer itself does anything canny under the covers to retry).

Obviously our test suite *is* a calling application, and so it makes
perfect sense to put some workaround in place.

The trouble with this class of problem, where a share-delete handle
allows operations to succeed and to fail later which would normally fail
early, is that the bad effect is at one remove from its cause. Here, by
the time the rmtree has reached the point of removing a parent
directory, it's long-since left behind the file which has a still-open
handle: the DeleteFile succeeded and the code moved on. You can't even
tell which file it was.

A related problem arises where the DeleteFile succeeds and an error
occurs when a subsequent CreateFile fails for the same filepath, again
because a share-delete handle is still open for a file at that path.
This is another one which hits our test suite because of an overuse of
one temp filename.

What should Python do? With some effort it could look for open file
handles against the file it's trying to delete, but what then? Wait
until they're all closed? That could leave it hanging. And even with a
timeout it would introduce a delay which might be unnecessary. A lot of
the time, no harm will come of the file existing a few seconds after the
DeleteFile has succeeded.

In short, I don't believe there's any mileage in introducing extra code
into Python's os or io modules. It falls on the shoulders of the calling
code to implement retry loops or whatever logic as needed.

TJG
___
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] windows file closing race condition?

[Chris Withers]

On 06/09/2013 08:14, Nick Coghlan wrote:

This feels a lot like an issue we were seeing on the Windows
buildbots, which we ended up working around in the test support
library: http://bugs.python.org/issue15496


Wow :'(


That would be some awfully ugly code to upgrade from "hack in the test
support library" to "this is just how Python unlinks files on
Windows", though :P


Indeed...

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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] windows file closing race condition?

[Antoine Pitrou]

Le Fri, 06 Sep 2013 08:58:06 +0100,
Tim Golden  a écrit :
> 
> What should Python do?

Maybe using FILE_SHARE_DELETE could help?
http://bugs.python.org/issue15244

Regards

Antoine.


___
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] windows file closing race condition?

[Tim Golden]

On 06/09/2013 11:14, Antoine Pitrou wrote:
> Le Fri, 06 Sep 2013 08:58:06 +0100,
> Tim Golden  a écrit :
>>
>> What should Python do?
> 
> Maybe using FILE_SHARE_DELETE could help?
> http://bugs.python.org/issue15244

I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
eg Virus Checkers) that typically causes the problem. IOW, the sequence is:

* [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
programs to delete the file even while this handle is still open

* Python calls DeleteFile -- succeeds if the only open handles are
FILE_SHARE_DELETE; carries on

* File has apparently disappeared but still has open handles

* Any attempt to create a file of the same name or to delete a
containing directory fail because the file is still open, even though
it's successfully been deleted.

* (Some time later) [Some Other Prog] closes its handle and the file is
now completely gone


Unless I'm missing something, there's nothing Python can do to help here
apart from the sort of delay-retry dance which test.support uses and
which I'm advocating against as a core feature.


TJG
___
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] windows file closing race condition?

[Richard Oudkerk]

On 06/09/2013 11:23am, Tim Golden wrote:

On 06/09/2013 11:14, Antoine Pitrou wrote:

Le Fri, 06 Sep 2013 08:58:06 +0100,
Tim Golden  a écrit :


What should Python do?


Maybe using FILE_SHARE_DELETE could help?
http://bugs.python.org/issue15244


I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
eg Virus Checkers) that typically causes the problem. IOW, the sequence is:

* [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
programs to delete the file even while this handle is still open

* Python calls DeleteFile -- succeeds if the only open handles are
FILE_SHARE_DELETE; carries on

* File has apparently disappeared but still has open handles

* Any attempt to create a file of the same name or to delete a
containing directory fail because the file is still open, even though
it's successfully been deleted.

* (Some time later) [Some Other Prog] closes its handle and the file is
now completely gone


Unless I'm missing something, there's nothing Python can do to help here
apart from the sort of delay-retry dance which test.support uses and
which I'm advocating against as a core feature.


Instead of deleting, the file could be moved to a temporary name in the 
root directory (or some other permanent directory on the same drive) and 
then deleted.  That would allow the directory to be closed even if a 
FILE_SHARE_DELETE handle is still open for the file.


--
Richard

___
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] windows file closing race condition?

[Tim Golden]

On 06/09/2013 12:50, Richard Oudkerk wrote:
> On 06/09/2013 11:23am, Tim Golden wrote:
>> On 06/09/2013 11:14, Antoine Pitrou wrote:
>>> Le Fri, 06 Sep 2013 08:58:06 +0100,
>>> Tim Golden  a écrit :

 What should Python do?
>>>
>>> Maybe using FILE_SHARE_DELETE could help?
>>> http://bugs.python.org/issue15244
>>
>> I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
>> eg Virus Checkers) that typically causes the problem. IOW, the
>> sequence is:
>>
>> * [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
>> programs to delete the file even while this handle is still open
>>
>> * Python calls DeleteFile -- succeeds if the only open handles are
>> FILE_SHARE_DELETE; carries on
>>
>> * File has apparently disappeared but still has open handles
>>
>> * Any attempt to create a file of the same name or to delete a
>> containing directory fail because the file is still open, even though
>> it's successfully been deleted.
>>
>> * (Some time later) [Some Other Prog] closes its handle and the file is
>> now completely gone
>>
>>
>> Unless I'm missing something, there's nothing Python can do to help here
>> apart from the sort of delay-retry dance which test.support uses and
>> which I'm advocating against as a core feature.
> 
> Instead of deleting, the file could be moved to a temporary name in the
> root directory (or some other permanent directory on the same drive) and
> then deleted.  That would allow the directory to be closed even if a
> FILE_SHARE_DELETE handle is still open for the file.
> 

True, but then you're into determining a temporary name somewhere on the
same volume if possible and avoiding collisions etc. Again, I don't
think this is something we need to be doing by default in core Python.

TJG
___
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] windows file closing race condition?

[Paul Moore]

On 6 September 2013 13:21, Tim Golden  wrote:
> True, but then you're into determining a temporary name somewhere on the
> same volume if possible and avoiding collisions etc. Again, I don't
> think this is something we need to be doing by default in core Python.

Agreed.

There simply is no solution that works in all cases. If you rename the
file to anywhere but the same directory, you potentially have
permission issues. And if you rename to the same directory, you still
can't delete the directory. It's a shame, because a helper to do this
would be useful for Unix users wanting to ensure that their code works
properly on Windows, but there really isn't an answer other than
knowing how things work (and crafting an appropriate solution for your
application), here...

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

Re: [Python-Dev] windows file closing race condition?

[Richard Oudkerk]

On 06/09/2013 1:55pm, Paul Moore wrote:

... If you rename the
file to anywhere but the same directory, you potentially have
permission issues.


Using the root directory avoids permission issues -- users always have 
write access there.


--
Richard

___
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] windows file closing race condition?

[R. David Murray]

On Fri, 06 Sep 2013 13:21:35 +0100, Tim Golden  wrote:
> On 06/09/2013 12:50, Richard Oudkerk wrote:
> > On 06/09/2013 11:23am, Tim Golden wrote:
> >> On 06/09/2013 11:14, Antoine Pitrou wrote:
> >>> Le Fri, 06 Sep 2013 08:58:06 +0100,
> >>> Tim Golden  a écrit :
> 
>  What should Python do?
> >>>
> >>> Maybe using FILE_SHARE_DELETE could help?
> >>> http://bugs.python.org/issue15244
> >>
> >> I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
> >> eg Virus Checkers) that typically causes the problem. IOW, the
> >> sequence is:
> >>
> >> * [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
> >> programs to delete the file even while this handle is still open
> >>
> >> * Python calls DeleteFile -- succeeds if the only open handles are
> >> FILE_SHARE_DELETE; carries on
> >>
> >> * File has apparently disappeared but still has open handles
> >>
> >> * Any attempt to create a file of the same name or to delete a
> >> containing directory fail because the file is still open, even though
> >> it's successfully been deleted.
> >>
> >> * (Some time later) [Some Other Prog] closes its handle and the file is
> >> now completely gone
> >>
> >>
> >> Unless I'm missing something, there's nothing Python can do to help here
> >> apart from the sort of delay-retry dance which test.support uses and
> >> which I'm advocating against as a core feature.
> > 
> > Instead of deleting, the file could be moved to a temporary name in the
> > root directory (or some other permanent directory on the same drive) and
> > then deleted.  That would allow the directory to be closed even if a
> > FILE_SHARE_DELETE handle is still open for the file.
> > 
> 
> True, but then you're into determining a temporary name somewhere on the
> same volume if possible and avoiding collisions etc. Again, I don't
> think this is something we need to be doing by default in core Python.

What about moving the test.support delete helper to somewhere in
unittest, since this will come up in pretty much every test suite that
runs on Windows?

--David
___
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] inspect and metaclasses

[Ethan Furman]

Part of the fix for issue #18693  is to fix inspect to look in the metaclass for class attributes 
(http://bugs.python.org/issue18929).


In inspect.py in function get_mro() we can either add the metaclass 
unconditionally, or only if it is not 'type'.

If we add unconditionally, then help() adds the following:

  class A(builtins.object)
   |  Hello and goodbye
+  |
+  |  Method resolution order:
+  |  A
+  |  builtins.object
+  |  builtins.type
   |
   |  Methods defined here:

Do we want that, or should we just add the metaclass if it is not 'type'?

--
~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] windows file closing race condition?

[Paul Moore]

On 6 September 2013 14:16, Richard Oudkerk  wrote:
> On 06/09/2013 1:55pm, Paul Moore wrote:
>>
>> ... If you rename the
>>
>> file to anywhere but the same directory, you potentially have
>> permission issues.
>
>
> Using the root directory avoids permission issues -- users always have write
> access there.

I don't believe that's true. IIRC, some Windows versions protect the
root of the system drive from non-admin users. And I *know* I have had
problems with NTFS-formatted removable drives plugged into systems
they were not originally formatted on, where the owner of the drive no
longer exists. They are rare corner cases, for sure, but they do
happen and frankly are probably harder to explain when they come up
than saying "your virus checker is interfering". Everyone expects
their virus checker to screw up their system (cure worse than disease
syndrome :-))

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

Re: [Python-Dev] SEEK_* constants in io and os

[Eli Bendersky]

> On Mon, Sep 2, 2013 at 8:48 AM, Victor Stinner 
> wrote:
>
>> 2013/9/2 Eli Bendersky :
>> > Yes, now I see a 500 usec difference timed within the Python script.
>> When
>> > timing the whole execution of Python: (...)
>>
>> Can you please provide the list of imported modules by:
>> python -c 'import sys; print(sys.modules)'
>>
>> For python with default options and for python with -S (no site
>> module) options? And also with your patch?
>>
>> Python should be fast to write "hello world" (or "python -c pass),
>> it's a dummy but common benchmark (to compare Python to other VM /
>> other programming languages).
>>
>
> The sorted list for both default and -S (they're identical) is
> http://pastebin.com/4vzSMCu7 - there are 55 entries there, including
> things like itertools, heapq, functools and collections. With my patch,
> enum is also added (which makes sense since os is in the list). So the
> 0.5ms increase for the 34ms runtime kind-of makes sense.
>

This question is still kind-of open. I haven't received additional feedback
- only Antoine's and Victor's concerns wrt. runtime cost, which I believe I
addressed. Note that the runtime cost is globally one-time in the sense
that if additional modules (whether used at start-up or not) use enum, this
is a price only paid once.

So, is it worth it the extra 0.5ms of start-up time, or not?

Eli
___
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] SEEK_* constants in io and os

[Ethan Furman]

On 09/01/2013 06:02 PM, Eli Bendersky wrote:


os seems to import io in some functions; can this be done always? If yes, we 
can just define the constants once and
os.SEEK_* will alias io.SEEK_*? The other way (io taking from os) is also a 
possibility (maybe the preferred one because
io already refers to os.SEEK_HOLE/DATA, at least in the documentation).

Any ideas and suggestions are welcome,


Ideally we should only define them once.

If these are values that could change per O/S then they should be in the os module.  Since they /can/ change per O/S 
(even if they don't currently), we should put them in os.


I'd say it's worth the extra 0.5ms startup time.

--
~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] inspect and metaclasses

[Armin Rigo]

Hi Ethan,

Are you suggesting that inspect.get_mro(A) would return (A, object,
type)?  That seems very wrong to me.

If the goal is to fix `inspect.classify_class_attrs()`, then this
function only needs a specific fix, along the lines of looking in
`get_mro(A) + get_mro(type(A))`.  (A more minor issue is that the bug
report suggests `... + (type(A),)` only, but that's wrong: Python will
also look in all the base classes of type(A).)

"Fixing" inspect.get_mro() as suggested would break a lot of other usages of it.


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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 17:18, Skip Montanaro wrote:
> I looked at this several years ago. As I recall, the problem at the
> time was that the Apple and Sun DTrace implementations were
> incompatible, or that the probes they had inserted into their own
> /usr/bin/python instances were incompatible. (Don't remember which
> off the top of my head.) Of course, the DTrace folks at Apple and
> Sun weren't really interested in holding hands...

Right. They use two different set of probes because Python doesn't
provide "official" probes :-).

If I recall correctly, they were basically identical, with an extra
parameter somewhere. I think my patch provides a superset.

Anyway, I don't think neither of them support Python 3. Time to step
in and liderate.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUinzmJlgi5GaxT1NAQLxwQP/cTq90CCfZhiUVLsutP0dQk4Br62kvCyn
mmMV9E/ZPJEO3LYYQT+CSiIRnG5panqdZulMDAGBBvgIbJP/E8spuyoFZkspWtPM
fk5n2etHq8JMZs36mbxnhw++W3/jlZ4osdVWZZKoKdwVBRFz2YvpLa24q+Y06gU/
5YEXHuNDP/4=
=YFm2
-END PGP SIGNATURE-
___
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] DTRACE support

[Skip Montanaro]

> I have spend a very long time on a patch for Dtrace support in most
> platforms with dtrace available. Currently working under Solaris and
> derivatives, and MacOS X. Last time I checked, it would crash FreeBSD
> because bugs in the dtrace port, but that was a long time ago.

I looked at this several years ago. As I recall, the problem at the time was
that the Apple and Sun DTrace implementations were incompatible, or that
the probes they had inserted into their own /usr/bin/python instances were
incompatible. (Don't remember which off the top of my head.) Of course, the
DTrace folks at Apple and Sun weren't really interested in holding hands...

Skip
___
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] unicodedata module is out of date

[Andrew Miller]

The unicodedata module only contains data up to Unicode 5.2 (October 2009),
so attempting to reference any character from a later version e.g:

unicodedata.lookup("TURKISH LIRA SIGN")

results in a KeyError.

Also, it seems to be limited to properties in the UnicodeData.txt file and
does not contain any data from the other files from the Unicode Character
Database (the perl library Unicode::UCD is far more complete).

Are there any plans to update this module to the latest Unicode version
(6.2, with 6.3 being released shortly), or is there another module that
provides more up to date information?

Thanks,

Andrew
___
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] Details of "import lock" in 3.3

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

With importlib and other recent changes, what are the current details
of "import lock"?. That is, the lock/locks held when Python code does
"import", specially in the case of multithreading. Is that documented
anywhere?

Thanks!

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUinv7Jlgi5GaxT1NAQLX7QP/SBNuy869xSKRVNlWmAiDLpZOR9IHm77K
fy+AG/aJDpk4BMcm+KNoHZyUtJJs2kndfz+OVTeU/mmlr+aXu/wA1yNB1HAjAwWO
4ZWyaN9WLrhv8xXomUlT8iqikc/9pEspgQbJAljUvMLVouixIdxga3IqtaT3FQZh
wkV9v04G4OA=
=P3PI
-END PGP SIGNATURE-
___
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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As far as I know, Erlang, Ruby, PHP, Perl, etc., support Dtrace.
Python is embarrasingly missing from this list.

Some examples:





I have spend a very long time on a patch for Dtrace support in most
platforms with dtrace available. Currently working under Solaris and
derivatives, and MacOS X. Last time I checked, it would crash FreeBSD
because bugs in the dtrace port, but that was a long time ago.

I would like to push this to Python 3.4, and the window is going to be
closed soon, so I think this is the time to ask for opinions and
support here.

Does Python-Dev have any opinion or interest in this project?. Should
I push for it?

Some (not current) details: http://bugs.python.org/issue13405

DTrace is amazing: http://dtrace.org/blogs/

PS: I can't release this code as a PyPI project, because it mess with
the inner core of Python.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUinv55lgi5GaxT1NAQIK7gP8DeaWxNVwNFa5PnfZe00Aay5l1rWzgj8d
CY0D3W+PAdPkBci9SYPmfv7ajXrQWo/ccANYIRaUdI/U9Zjq/od7eNemOFqyL7U6
BrQpAUMySI6tMlL+gYEfQ8O47SManvTqoyNvOFAz9mVJute8IxKsbCIK/jiRHDXz
vWyG7YrYN1A=
=4E7+
-END PGP SIGNATURE-
___
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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 17:08, Jesus Cea wrote:
> Does Python-Dev have any opinion or interest in this project?.
> Should I push for it?

I have using this code for ages on my Solaris machines:

Python 2.7.5 (dtrace-issue13405_2.7:f96ea83cd766, Aug 19 2013, 02:55:15)

Python 3.3.2 (dtrace-issue13405_3.3:23dafaf73d29, Aug 19 2013, 05:52:34)

Python 3.4.0a1+ (dtrace-issue13405:d7be45bb06a3, Aug 19 2013, 07:03:24)

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUin0uJlgi5GaxT1NAQJP/wQAmkxZ5UJk9L+wTZb94icd3vqUGdo+mgR6
CNs0/oyemd7fL2DSaHGycqDwVPqyqNVFE+aD/ziEmWOwmiFQebudX0Z7md4ZSF89
LU4ddBPMj1bI5E/EYtlqgZg4TqwbUP3XPy9IrCEeiiSKcIk2TJxYiZ12IlcFyXU+
ff3E+DyDkBY=
=svJD
-END PGP SIGNATURE-
___
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] when to fix cross-version bugs?

[Brian Curtin]

On Fri, Sep 6, 2013 at 9:51 AM, Ethan Furman  wrote:
> I recently committed a fix for unicodeobject.c so that the %d, %i, and %u
> format specifiers always output values (otherwise, in subclasses, the str()
> was used instead).
>
> Should this be fixed in 3.3 as well?
>
> What guidelines determine when a bug is fixed in previous versions?

If it's a bug in that version and the version is accepting bug fixes,
i.e., not in security mode, go for it. This includes crossing the 2/3
boundary if applicable.
___
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] when to fix cross-version bugs?

[Ethan Furman]

I recently committed a fix for unicodeobject.c so that the %d, %i, and %u format specifiers always output values 
(otherwise, in subclasses, the str() was used instead).


Should this be fixed in 3.3 as well?

What guidelines determine when a bug is fixed in previous versions?

--
~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] DTRACE support

[Guido van Rossum]

I've heard good things about DTRACE but never used it myself.

Do I understand correctly that you have to build a separate Python
executable with it turned on?

I noticed one odd thing in the patch: apparently the dtrace module
only exists to have a flag that tells whether it is enabled. Can't
that flag be added to the sys module?

On Fri, Sep 6, 2013 at 8:08 AM, Jesus Cea  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As far as I know, Erlang, Ruby, PHP, Perl, etc., support Dtrace.
> Python is embarrasingly missing from this list.
>
> Some examples:
>
> 
> 
> 
>
> I have spend a very long time on a patch for Dtrace support in most
> platforms with dtrace available. Currently working under Solaris and
> derivatives, and MacOS X. Last time I checked, it would crash FreeBSD
> because bugs in the dtrace port, but that was a long time ago.
>
> I would like to push this to Python 3.4, and the window is going to be
> closed soon, so I think this is the time to ask for opinions and
> support here.
>
> Does Python-Dev have any opinion or interest in this project?. Should
> I push for it?
>
> Some (not current) details: http://bugs.python.org/issue13405
>
> DTrace is amazing: http://dtrace.org/blogs/
>
> PS: I can't release this code as a PyPI project, because it mess with
> the inner core of Python.
>
> - --
> Jesús Cea Avión _/_/  _/_/_/_/_/_/
> j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> Twitter: @jcea_/_/_/_/  _/_/_/_/_/
> jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQCVAwUBUinv55lgi5GaxT1NAQIK7gP8DeaWxNVwNFa5PnfZe00Aay5l1rWzgj8d
> CY0D3W+PAdPkBci9SYPmfv7ajXrQWo/ccANYIRaUdI/U9Zjq/od7eNemOFqyL7U6
> BrQpAUMySI6tMlL+gYEfQ8O47SManvTqoyNvOFAz9mVJute8IxKsbCIK/jiRHDXz
> vWyG7YrYN1A=
> =4E7+
> -END PGP SIGNATURE-
> ___
> 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] DTRACE support

[Charles-François Natali]

> As far as I know, Erlang, Ruby, PHP, Perl, etc., support Dtrace.
> Python is embarrasingly missing from this list.
>
> Some examples:
>
> 
> 
> 
>
> I have spend a very long time on a patch for Dtrace support in most
> platforms with dtrace available. Currently working under Solaris and
> derivatives, and MacOS X. Last time I checked, it would crash FreeBSD
> because bugs in the dtrace port, but that was a long time ago.
>
> I would like to push this to Python 3.4, and the window is going to be
> closed soon, so I think this is the time to ask for opinions and
> support here.
>
> Does Python-Dev have any opinion or interest in this project?. Should
> I push for it?

IMO, that's a large, intrusive patch, which distracts the reader from
the main code and logic.

Here's an extract from Modules/gcmodule.c:

static void
dtrace_gc_done(Py_ssize_t value)
{
PYTHON_GC_DONE((long) value);
/*
* Currently a USDT tail-call will not receive the correct arguments.
* Disable the tail call here.
*/
#if defined(__sparc)
asm("nop");
#endif
}

Also have a look at cevalc.c:
http://bugs.python.org/review/13405/diff/6152/Python/ceval.c


IMO it's not worth it (personally strace/gdb/valgrind are more than
enough for me, and we''re about to gain memory tracing with Victor's
tracemalloc).

cf
___
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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 17:14, Guido van Rossum wrote:
> I've heard good things about DTRACE but never used it myself.
> 
> Do I understand correctly that you have to build a separate Python 
> executable with it turned on?

It is a patch you apply on stock Python and you get a new configure
option: "--with-dtrace". If you compile Python with that flag, you get
a python interpreter with dtrace probes on it.

> I noticed one odd thing in the patch: apparently the dtrace module 
> only exists to have a flag that tells whether it is enabled. Can't 
> that flag be added to the sys module?

My plan is to (in the future) use that module to create new probes on
the fly, like
,
and to export functions to communicate data to dtrace scripts, if running.

That is, this module is currently a shell I plan to fill.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUiny4plgi5GaxT1NAQLngQP/eFoQ3rdPy12nmw8pPPO/+/RYjlhIi67+
T0n1xBJbxIvpFpIRufB+tkCfLWdb7YZKcf3Nb4V6pVsOPdbd9s6RcVWNA9Ds5mNx
ISrO644CAIqRF5XgeeS5uhsODL1DrZTEfX0QBhGsU6lcqyOzSfRX2t9hRBMh3f5y
2dPMHNznJhs=
=dV5g
-END PGP SIGNATURE-
___
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] unicodedata module is out of date

[R. David Murray]

On Fri, 06 Sep 2013 10:54:45 +0100, Andrew Miller  wrote:
> Are there any plans to update this module to the latest Unicode version
> (6.2, with 6.3 being released shortly), or is there another module that
> provides more up to date information?

Python 3.4 currently has 6.2.  If 6.3 gets released before the first RC,
I'm guessing we will probably upgrade to it.

--David
___
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] inspect and metaclasses

[Ethan Furman]

On 09/06/2013 07:47 AM, Armin Rigo wrote:


Are you suggesting that inspect.getmro(A) would return (A, object,
type)?  That seems very wrong to me.


Currently, `inspect.getmro(A)` returns `(A, object)`.

Considering that Python actually will look in A's metaclass to find a class attribute, I think returning `(A, object, 
type(A)` is appropriate:


=
Python 3.4.0a1+ (default:61ca4732399b+, Sep  4 2013, 22:28:04)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
--> class Meta(type):
...   meta_attr = 42
...

--> class Class(metaclass=Meta):
...   cls_attr = 'Vitamin-soaked towel'
...   def __init__(self):
... self.inst_attr = 'dolphins'
...

--> test = Class()

--> test.inst_attr
'dolphins'

--> test.cls_attr
'Vitamin-soaked towel'

--> test.meta_attr
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'Class' object has no attribute 'meta_attr'

--> Class.cls_attr
'Vitamin-soaked towel'

--> Class.meta_attr
42

--> import inspect

--> inspect.getmro(Class)  #  with patch in place
(, , )
=


If the goal is to fix `inspect.classify_class_attrs()`, then this
function only needs a specific fix, along the lines of looking in
`getmro(A) + getmro(type(A))`.  (A more minor issue is that the bug
report suggests `... + (type(A),)` only, but that's wrong: Python will
also look in all the base classes of type(A).)


Good point.  Will incorporate that into the final fix, whichever way it ends up.



"Fixing" inspect.getmro() as suggested would break a lot of other usages of it.


Any examples?

--
~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] unicodedata module is out of date

[R. David Murray]

On Fri, 06 Sep 2013 17:33:47 +0200, Stefan Behnel  wrote:
> Andrew Miller, 06.09.2013 11:54:
> > The unicodedata module only contains data up to Unicode 5.2 (October 2009),
> > so attempting to reference any character from a later version e.g:
> > 
> > unicodedata.lookup("TURKISH LIRA SIGN")
> > 
> > results in a KeyError.
> > 
> > Also, it seems to be limited to properties in the UnicodeData.txt file and
> > does not contain any data from the other files from the Unicode Character
> > Database (the perl library Unicode::UCD is far more complete).
> > 
> > Are there any plans to update this module to the latest Unicode version
> > (6.2, with 6.3 being released shortly)
> 
> It's been updated to 6.2 almost a year ago, so Python 3.3 should have that.

3.3 shipped with 6.1.

--David
___
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] DTRACE support

[Antoine Pitrou]

Le Fri, 06 Sep 2013 17:08:23 +0200,
Jesus Cea  a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> As far as I know, Erlang, Ruby, PHP, Perl, etc., support Dtrace.
> Python is embarrasingly missing from this list.
> 
> Some examples:
> 
> 
> 
> 
> 
> I have spend a very long time on a patch for Dtrace support in most
> platforms with dtrace available. Currently working under Solaris and
> derivatives, and MacOS X. Last time I checked, it would crash FreeBSD
> because bugs in the dtrace port, but that was a long time ago.
> 
> I would like to push this to Python 3.4, and the window is going to be
> closed soon, so I think this is the time to ask for opinions and
> support here.

You should start by addressing review comments:
http://bugs.python.org/issue13405#msg151751

Right now, I agree with Charles-François: your patch is too intrusive.

Regards

Antoine.


___
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] inspect and metaclasses

[R. David Murray]

On Fri, 06 Sep 2013 08:14:09 -0700, Ethan Furman  wrote:
> On 09/06/2013 07:47 AM, Armin Rigo wrote:
> >
> > Are you suggesting that inspect.getmro(A) would return (A, object,
> > type)?  That seems very wrong to me.
> 
> Currently, `inspect.getmro(A)` returns `(A, object)`.

Which matches A.__mro__.  EOD, I think.

--David
___
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] unicodedata module is out of date

[Stefan Behnel]

Andrew Miller, 06.09.2013 11:54:
> The unicodedata module only contains data up to Unicode 5.2 (October 2009),
> so attempting to reference any character from a later version e.g:
> 
> unicodedata.lookup("TURKISH LIRA SIGN")
> 
> results in a KeyError.
> 
> Also, it seems to be limited to properties in the UnicodeData.txt file and
> does not contain any data from the other files from the Unicode Character
> Database (the perl library Unicode::UCD is far more complete).
> 
> Are there any plans to update this module to the latest Unicode version
> (6.2, with 6.3 being released shortly)

It's been updated to 6.2 almost a year ago, so Python 3.3 should have that.

I don't think 6.3 support will be added before Python 3.4, assuming it's
final by then. You should open a ticket so that it won't be forgotten
before the release.

http://bugs.python.org/

That being said, the module is (mostly) generated, so you might be able to
fix it up yourself if you need it sooner in a local installation.

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/archive%40mail-archive.com

Re: [Python-Dev] when to fix cross-version bugs?

[R. David Murray]

On Fri, 06 Sep 2013 07:51:06 -0700, Ethan Furman  wrote:
> I recently committed a fix for unicodeobject.c so that the %d, %i, and %u 
> format specifiers always output values 
> (otherwise, in subclasses, the str() was used instead).
>
> Should this be fixed in 3.3 as well?
> 
> What guidelines determine when a bug is fixed in previous versions?

The basic guideline is: we try very hard not to break currently working
code in a maintenance release.  Making that decision very much depends on
the details of each individual case.

I'd say this one is borderline...it would probably be OK to backport it,
since programs depending on the str of number subclasses (that is what
we are talking about here, right?  Even though you say the fix is in
unicodeobject.c...) are likely to be rare, or already have a workaround
that won't get broken by the change, but by the same token it probably
doesn't have much positive impact if it does get backported, so is it
worth the (small) chance of breaking someone's code?

--David
___
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] unicodedata module is out of date

[Benjamin Peterson]

2013/9/6 Andrew Miller :
> The unicodedata module only contains data up to Unicode 5.2 (October 2009),
> so attempting to reference any character from a later version e.g:
>
> unicodedata.lookup("TURKISH LIRA SIGN")
>
> results in a KeyError.
>
> Also, it seems to be limited to properties in the UnicodeData.txt file and
> does not contain any data from the other files from the Unicode Character
> Database (the perl library Unicode::UCD is far more complete).
>
> Are there any plans to update this module to the latest Unicode version
> (6.2, with 6.3 being released shortly), or is there another module that
> provides more up to date information?

I usually keep the latest Python version up to date with the latest
Unicode version, so 3.4 will have Unicode 6.2.

-- 
Regards,
Benjamin
___
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] inspect and metaclasses

[Ethan Furman]

On 09/06/2013 08:44 AM, R. David Murray wrote:

On Fri, 06 Sep 2013 08:14:09 -0700, Ethan Furman  wrote:

On 09/06/2013 07:47 AM, Armin Rigo wrote:


Are you suggesting that inspect.getmro(A) would return (A, object,
type)?  That seems very wrong to me.


Currently, `inspect.getmro(A)` returns `(A, object)`.


Which matches A.__mro__.  EOD, I think.


I hope not, because currently this leaves a hole in the introspection of class 
attributes.

Is __mro__ aimed primarily at instances and not classes?  That seems to be how it works.  In which case, do we need 
another __mmro__ (or __cmro__ or ...) to handle the mro of classes themselves?


For the short term I can restrict the change to inspect.classify_class_attrs().

--
~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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 17:41, Antoine Pitrou wrote:
> You should start by addressing review comments: 
> http://bugs.python.org/issue13405#msg151751

Antoine, my first step now is to poke Python-DEV about this subject.
If the consensus is "DON'T" I will probably maintain this patch by
myself. I saw big "BUTs" with this work in the bug tracker, so I
rather prefer to ask for actual interest before investing in iron out
patch implementation details.

If devs actually want it, then next step is to improve current work to
make it acceptable in mainline. There are quite a few ugly corners I
would love to file out, beside your (really valuable) feedback.

That is how I see it.

> Right now, I agree with Charles-François: your patch is too
> intrusive.

It is intrusive. Yes. I think it must be, by its own nature. Probably
room for improvement and code transparency. But... are Python-DEVs
interested in the project?. That is the point :)

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUin/Yplgi5GaxT1NAQI6tAP+MaGbSm8j3xPBjMui9tePg2engB+G/ckh
TzVac8Gz5yhWhixOFLk3cXYySieB6ttjsAG1NZYKxIwyLSLrxcL8pTh4c8oHB8zu
/wYfIdXt6leH6HECXJquPLxLM39Z6KIOTt2QgKYSWy6ZHGzVaaeTFvrMhW0N/5rp
SCHSJQc7Vn4=
=65h4
-END PGP SIGNATURE-
___
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] Fwd: unicodedata module is out of date

[Andrew Miller]

The unicodedata module only contains data up to Unicode 5.2 (October 2009),
so attempting to reference any character from a later version e.g:

unicodedata.lookup("TURKISH LIRA SIGN")

results in a KeyError.

Also, it seems to be limited to properties in the UnicodeData.txt file and
does not contain any data from the other files from the Unicode Character
Database (the perl library Unicode::UCD is far more complete).

Are there any plans to update this module to the latest Unicode version
(6.2, with 6.3 being released shortly), or is there another module that
provides more up to date information?

Thanks,

Andrew
___
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] unicodedata module is out of date

[Andrew Miller]

I've just checked on Python 2.7.5 and Python 3.3.2 (Win32 versions).

In Python 3.3.2 unicodedata.unidata_version is set to '6.1.0'.

In Python 2.7.5 it is set to '5.2.0' so it looks as though this version is
no longer being updated.

Since my initial post I've downloaded the Python 2.7.5 source and have
found the makeunicodedata.py script which creates this module.

Are there plans to add the extra data from the other UCD files to this
module?  At the moment I am using a module from
https://gist.github.com/anonymous/2204527 to obtain the script of a
character but it would be nice if this was available from the standard
library.


On 6 September 2013 16:38, MRAB  wrote:

> On 06/09/2013 10:54, Andrew Miller wrote:
>
>> The unicodedata module only contains data up to Unicode 5.2 (October
>> 2009), so attempting to reference any character from a later version e.g:
>>
>> unicodedata.lookup("TURKISH LIRA SIGN")
>>
>> results in a KeyError.
>>
>> Also, it seems to be limited to properties in the UnicodeData.txt file
>> and does not contain any data from the other files from the Unicode
>> Character Database (the perl library Unicode::UCD is far more complete).
>>
>> Are there any plans to update this module to the latest Unicode version
>> (6.2, with 6.3 being released shortly), or is there another module that
>> provides more up to date information?
>>
>>  Which version of Python are you talking about? Python 3.3 uses Unicode
> version 6.1.
>
> __**_
> 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/a.**
> j.miller%40bcs.org.uk
>
___
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] inspect and metaclasses

[R. David Murray]

On Fri, 06 Sep 2013 08:59:02 -0700, Ethan Furman  wrote:
> On 09/06/2013 08:44 AM, R. David Murray wrote:
> > On Fri, 06 Sep 2013 08:14:09 -0700, Ethan Furman  wrote:
> >> On 09/06/2013 07:47 AM, Armin Rigo wrote:
> >>>
> >>> Are you suggesting that inspect.getmro(A) would return (A, object,
> >>> type)?  That seems very wrong to me.
> >>
> >> Currently, `inspect.getmro(A)` returns `(A, object)`.
> >
> > Which matches A.__mro__.  EOD, I think.
> 
> I hope not, because currently this leaves a hole in the introspection of 
> class attributes.
> 
> Is __mro__ aimed primarily at instances and not classes?  That seems to be 
> how it works.  In which case, do we need 
> another __mmro__ (or __cmro__ or ...) to handle the mro of classes themselves?

Or maybe just a new inspect function?

> For the short term I can restrict the change to 
> inspect.classify_class_attrs().

Sounds like the best course.

--David
___
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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 17:29, Charles-François Natali wrote:
> IMO, that's a large, intrusive patch, which distracts the reader
> from the main code and logic.

Yes, the patch is intrusive. It must be, to get its goals. Could be
improved, nevertheless. Help and suggestions welcome.

I want to write a probe for the GIL, but I didn't because I know
adding the cost of an extra single machine code branch would be
anathema here :-) (lets do baby steps), but I would love to be able to
watch with detail all interaction between the GIL, threads, and OS
scheduling on my Solaris :). That is very valuable information to
have, for instance, to guide future improvements of the GIL. How can
you get that kind of information with any other tool?

> IMO it's not worth it (personally strace/gdb/valgrind are more
> than enough for me, and we''re about to gain memory tracing with
> Victor's tracemalloc).

The main value of DTrace is systemwide observability. You can see
something "strange" at kernel level and trace it to a particular line
of code in a random Python script. There is no other tool that can do
that. You have complete transversal observability of ALL the code
running in your computer, kernel or usermode, clean reports with
threads, etc.

Valgrind doesn't work on Solaris and *BSD support is unclean.

You can run a dtrace script in a long running python process if you
need it, after launching it, at runtime, and when the dtrace script is
done, the python program keeps running without any penalty. Just
poking around, for instance. I do it constantly for, for instance,
profiling covering both Python as any C code/libraries called from it.

Maybe the biggest objection would be that most python-devs are running
Linux, and you don't have dtrace support on linux unless you are
running Oracle distribution. But world is larger than linux, and there
are some efforts to port DTrace to Linux itself. DTrace is available
on Solaris and derivatives, MacOS X and FreeBSD.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUin7CJlgi5GaxT1NAQKbfwP+PjOqf3pjlHHq78ggA8qyNkjPFXEoRVj9
9PKslZ7FiU+JWxzXY52k1GNspHhIox+PAcvdBL/gWU3rOiqjEm5fU8FX61Lh6FMj
bB+QRyZLpLfmANrLX43sBvwDbG9gTuq8FVUvqmtSme615vX2ygITwNZysQ7xPoD/
jXbeOAF0LZU=
=asEC
-END PGP SIGNATURE-
___
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] Offtopic: OpenID Providers

[Dan Callahan]

On 9/5/13 12:31 PM, Jesus Cea wrote:

I have big hopes for Mozilla Persona, looking forward
Python infrastructure support :).


Hi, I'm the project lead on Persona signin, and I spoke at PyCon earlier 
this year regarding why and how Mozilla is building Persona. If you'd 
like some more background, that video [0] is worth a look.


Let's pull this discussion up a level:

It sounds like many people (Jesus, Donald, Toshio, Barry, Tres, Dirkjan, 
etc.) are interested in seeing Persona on Python.org properties, and 
most of the objections coming from a place of "Persona hasn't gone 
viral, what if this is wasted effort?"


We can tackle that from two angles:

1. Dirkjan and I are willing to do the work to make this happen if 
someone from python-devel is willing to guide us through the contributor 
process for these systems.


2. There's a seamless migration path away from Persona if we fail: fall 
back to the pre-existing traditional email/password system using the 
same email addresses that Persona had previously been in charge of 
verifying.


So let's do this. The open web deserves better than just Google+, 
Facebook, or Passwords, and visible support from the Python community 
would be a huge step toward answering the chicken-and-egg objections 
raised in this thread.


At your service,
-Callahad

PS: Freeform OpenID has utterly failed as a user-empowering 
authentication system, and the protocol itself is rapidly being 
supplanted by vendor-specific OAuth[1] systems. If we want to ensure 
that "you *can* (not *must*) use free and open services to access our 
resources," then we must provide an option to use something akin to Persona.


[0]: http://pyvideo.org/video/1764

[1]: "Google's OpenID service is being replaced by Login with OAuth 
2.0." https://developers.google.com/accounts/docs/GettingStarted


___
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] DTRACE support

[Charles-François Natali]

> The main value of DTrace is systemwide observability. You can see
> something "strange" at kernel level and trace it to a particular line
> of code in a random Python script. There is no other tool that can do
> that. You have complete transversal observability of ALL the code
> running in your computer, kernel or usermode, clean reports with
> threads, etc.

Don't get me wrong, I'm not saying DTrace is useless.
I'm just saying that, as far as I'm concerned, I've never had any
trouble debugging/tunning a Python script with non-intrusive tools
(strace, gdb, valgrind, and oprofile for profiling). Of course, this
includes analysing bug reports.

> Maybe the biggest objection would be that most python-devs are running
> Linux, and you don't have dtrace support on linux unless you are
> running Oracle distribution. But world is larger than linux, and there
> are some efforts to port DTrace to Linux itself. DTrace is available
> on Solaris and derivatives, MacOS X and FreeBSD.

That's true, I might have a different opinion if I used Solaris. But
that's not the case, so te me, the cognitive overhead incurred by this
large patch isn't worth it.

So I'm -1, but that's a personal opinion :-)

cf
___
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] unicodedata module is out of date

[Terry Reedy]

On 9/6/2013 11:55 AM, Andrew Miller wrote:

I've just checked on Python 2.7.5 and Python 3.3.2 (Win32 versions).

In Python 3.3.2 unicodedata.unidata_version is set to '6.1.0'.

In Python 2.7.5 it is set to '5.2.0' so it looks as though this version
is no longer being updated.


In general, new features do not go into bugfix releases (x.y.z, where z 
>= 1). Updating the unidate_version add new features to the unicodedata 
module.


--
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] inspect and metaclasses

[Ethan Furman]

On 09/06/2013 09:37 AM, R. David Murray wrote:

On Fri, 06 Sep 2013 08:59:02 -0700, Ethan Furman  wrote:


For the short term I can restrict the change to inspect.classify_class_attrs().


Sounds like the best course.


There is one other function in inspect that calls getmro():

def getmembers(object, predicate=None):
"""Return all members of an object as (name, value) pairs sorted by name.
Optionally, only return members that satisfy a given predicate."""
if isclass(object):
mro = (object,) + getmro(object)

Should I add `+ getmro(type(object))` here as well?

--
~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] Details of "import lock" in 3.3

[Antoine Pitrou]

On Fri, 06 Sep 2013 18:02:32 +0200
Jesus Cea  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 06/09/13 17:43, Antoine Pitrou wrote:
> > Quick summary here: 
> > http://docs.python.org/3/whatsnew/3.3.html#a-finer-grained-import-lock
> >
> >  Otherwise, I'm afraid the source code has the most information,
> > e.g.: 
> > http://hg.python.org/cpython/file/1d88d04aade2/Lib/importlib/_bootstrap.py#l124
> 
> Yes,
> > 
> I was depending of the global import lock in my code. I am
> evaluating impact under Python 3.3.
> 
> Under Python 3.3, metafinder/loader MUST BE reentrant?.

No, they shouldn't have to. Normally, the global import lock is still
held at this point. However, it is best to check the code if you want
to be sure.

Regards

Antoine.


___
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] DTRACE support

[Antoine Pitrou]

On Fri, 06 Sep 2013 18:14:26 +0200
Jesus Cea  wrote:
> 
> > Right now, I agree with Charles-François: your patch is too
> > intrusive.
> 
> It is intrusive. Yes. I think it must be, by its own nature. Probably
> room for improvement and code transparency. But... are Python-DEVs
> interested in the project?. That is the point :)

Well, I'm not *personally* interested in anything that only addresses
Solaris, OS X and the like :)

And, no, it doesn't have to be *that* intrusive. Take a look at Dave
Malcolm's systemtap patch, which IIRC takes a much more sensible
approach.

Regards

Antoine.


___
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] Details of "import lock" in 3.3

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 17:43, Antoine Pitrou wrote:
> Quick summary here: 
> http://docs.python.org/3/whatsnew/3.3.html#a-finer-grained-import-lock
>
>  Otherwise, I'm afraid the source code has the most information,
> e.g.: 
> http://hg.python.org/cpython/file/1d88d04aade2/Lib/importlib/_bootstrap.py#l124

Yes,
> 
I was depending of the global import lock in my code. I am
evaluating impact under Python 3.3.

Under Python 3.3, metafinder/loader MUST BE reentrant?.

Can they count on the fact that they could be called concurrently by
multiple threads but NOT for importing the SAME module?.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUin8mJlgi5GaxT1NAQKQugP+N0VI/BhqKvcaUicu7YMR09VhFweoAE6h
c48ltOrhlWhrauYc9XYeoEPZ2ksl9/SDnMt83cE+qLunSBltkSbYv3j/0LXWyHwk
ZGjzh5vQGTgCu3/2iCkFWq/tSAsgUfk8YfbwPQK82L1gs7LbC5vt2jWlRwNQs0nl
2Sr1Nlbf7og=
=GL0o
-END PGP SIGNATURE-
___
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] DTRACE support

[Antoine Pitrou]

On Fri, 06 Sep 2013 18:14:26 +0200
Jesus Cea  wrote:
> 
> It is intrusive. Yes. I think it must be, by its own nature. Probably
> room for improvement and code transparency. But... are Python-DEVs
> interested in the project?. That is the point :)

As a concrete data point:
- here are Dave's modifications to ceval.c for systemtap:
http://bugs.python.org/review/14776/diff/5177/Python/ceval.c
- here are your modifications to ceval.c for dtrace:
http://bugs.python.org/review/13405/diff/6151/Python/ceval.c

Regards

Antoine.


___
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] inspect and metaclasses

[R. David Murray]

On Fri, 06 Sep 2013 10:01:32 -0700, Ethan Furman  wrote:
> On 09/06/2013 09:37 AM, R. David Murray wrote:
> > On Fri, 06 Sep 2013 08:59:02 -0700, Ethan Furman  wrote:
> >>
> >> For the short term I can restrict the change to 
> >> inspect.classify_class_attrs().
> >
> > Sounds like the best course.
> 
> There is one other function in inspect that calls getmro():
> 
> def getmembers(object, predicate=None):
>  """Return all members of an object as (name, value) pairs sorted by name.
>  Optionally, only return members that satisfy a given predicate."""
>  if isclass(object):
>  mro = (object,) + getmro(object)
> 
> Should I add `+ getmro(type(object))` here as well?

Not unless you want to void the warranty on the docs :)

Note getmembers() does not return metaclass attributes when the
argument is a class (this behavior is inherited from the dir()
function).

--David
___
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 (2013-08-30 - 2013-09-06)
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:
  open4195 (+13)
  closed 26523 (+47)
  total  30718 (+60)

Open issues with patches: 1915 


Issues opened (43)
==

#16826: Don't check for PYTHONCASEOK if interpreter started with -E
http://bugs.python.org/issue16826  reopened by meador.inge

#18709: SSL module fails to handle NULL bytes inside subjectAltNames g
http://bugs.python.org/issue18709  reopened by neologix

#18886: BytesGenerator does not handle 'binary' CTE correctly
http://bugs.python.org/issue18886  opened by r.david.murray

#18887: test_multiprocessing.test_connection failure
http://bugs.python.org/issue18887  opened by neologix

#18890: Add a raw_data_manager content manager to the email package.
http://bugs.python.org/issue18890  opened by r.david.murray

#18891: Master patch for content manager addtion to email package.
http://bugs.python.org/issue18891  opened by r.david.murray

#18893: invalid exception handling in Lib/ctypes/macholib/dyld.py
http://bugs.python.org/issue18893  opened by scoder

#18894: In unittest.TestResult.failures remove deprecated fail* method
http://bugs.python.org/issue18894  opened by py.user

#18895: In unittest.TestResult.addError split the sentence
http://bugs.python.org/issue18895  opened by py.user

#18896: Remove namedtuple 255 arguments restriction
http://bugs.python.org/issue18896  opened by valorien

#18898: Apply the setobject optimizations to dictionaries
http://bugs.python.org/issue18898  opened by rhettinger

#18899: make pystone.py Py3 compatible in benchmark suite
http://bugs.python.org/issue18899  opened by scoder

#18900: Add the random.distrib module
http://bugs.python.org/issue18900  opened by serhiy.storchaka

#18902: Make ElementTree event handling more modular to allow custom t
http://bugs.python.org/issue18902  opened by eli.bendersky

#18903: IDLE file-completion is case-sensitive in Windows
http://bugs.python.org/issue18903  opened by anikom15

#18904: Unnecessary test in file descriptor inheritance test
http://bugs.python.org/issue18904  opened by vajrasky

#18905: pydoc -p 0 says the server is available at localhost:0
http://bugs.python.org/issue18905  opened by Wieland.Hoffmann

#18906: Create a way to always run tests in subprocesses within regrte
http://bugs.python.org/issue18906  opened by eli.bendersky

#18907: urllib2.open FTP open times out at 20 secs despite timeout par
http://bugs.python.org/issue18907  opened by nagle

#18908: Enum docs: sections leak out
http://bugs.python.org/issue18908  opened by elazar

#18910: IDLE: Unit test for textView.py
http://bugs.python.org/issue18910  opened by philwebster

#18911: minidom does not encode correctly when calling Document.writex
http://bugs.python.org/issue18911  opened by brianvanderburg2

#18913: ssl._ssl._test_decode_cert seems to leak memory with certain c
http://bugs.python.org/issue18913  opened by sYnfo

#18915: ssl.wrap_socket, pass in certfile and keyfile as PEM strings
http://bugs.python.org/issue18915  opened by mpb

#18916: Various out-of-date Lock text in 3.2+
http://bugs.python.org/issue18916  opened by tim.peters

#18917: python won't display greek characters in apache under windows
http://bugs.python.org/issue18917  opened by nickl1

#18918: help('FILES') finds no documentation
http://bugs.python.org/issue18918  opened by st.semp...@gmail.com

#18919: Unify audio modules tests
http://bugs.python.org/issue18919  opened by serhiy.storchaka

#18921: In imaplib, cached capabilities may be out of date after login
http://bugs.python.org/issue18921  opened by sjmurdoch

#18923: Use the new selectors module in the subprocess module
http://bugs.python.org/issue18923  opened by haypo

#18925: select.poll.modify is not documented
http://bugs.python.org/issue18925  opened by giampaolo.rodola

#18927: Lock.acquire() docs incorrect about negative timeout
http://bugs.python.org/issue18927  opened by tim.peters

#18929: inspect.classify_class_attrs ignores metaclass
http://bugs.python.org/issue18929  opened by ethan.furman

#18930: os.spawnXX functions terminates process if second argument is 
http://bugs.python.org/issue18930  opened by SSchukat

#18931: new selectors module should support devpoll on Solaris
http://bugs.python.org/issue18931  opened by giampaolo.rodola

#18932: selectors and modify()
http://bugs.python.org/issue18932  opened by giampaolo.rodola

#18934: multiprocessing: use selectors module
http://bugs.python.org/issue18934  opened by neologix

#18935: test_regrtest.test_timeout failure
http://bugs.python.org/issue18935  opened by neologix

#18936: getopt chokes on unicode option names
http://bugs.python.org/issue18936  opened by jason.coombs

#18937: add unittest assertion for logging
http://bugs.python.org/issue18937  opened by pitrou

#18943: argparse: default args in mutual

Re: [Python-Dev] Offtopic: OpenID Providers

[Donald Stufft]

On Sep 6, 2013, at 3:11 PM, "R. David Murray"  wrote:

> IMO, single signon is overrated.  Especially if one prefers not to make
> it easy for various accounts to be automatically associated with one
> another by various entities who shall remain nameless but have been in
> the news a lot lately :)

If I recall Persona doesn't leak this data like OpenID does, but perhaps Dan 
can speak to that better than I can.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] inspect and metaclasses

[Antoine Pitrou]

On Fri, 06 Sep 2013 08:14:09 -0700
Ethan Furman  wrote:
> On 09/06/2013 07:47 AM, Armin Rigo wrote:
> >
> > Are you suggesting that inspect.getmro(A) would return (A, object,
> > type)?  That seems very wrong to me.
> 
> Currently, `inspect.getmro(A)` returns `(A, object)`.
> 
> Considering that Python actually will look in A's metaclass to find a class 
> attribute, I think returning `(A, object, 
> type(A)` is appropriate:

No, I don't think it's appropriate at all. You are conflating two
things:
- the instance lookup of an attribute (on A, here)
- the class lookup when the instance lookup fails (on type, here)

Both lookups obey the same MRO rules, it just happens that the
second lookup uses a trivial MRO:

>>> type.__mro__
(, )


Regards

Antoine.


___
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] Offtopic: OpenID Providers

[R. David Murray]

On Fri, 06 Sep 2013 14:53:00 -0400, Donald Stufft  wrote:
> 
> On Sep 6, 2013, at 1:22 PM, Dan Callahan  wrote:
> 
> > On 9/5/13 12:31 PM, Jesus Cea wrote:
> >> I have big hopes for Mozilla Persona, looking forward
> >> Python infrastructure support :).
> > 
> > Hi, I'm the project lead on Persona signin, and I spoke at PyCon
> > earlier this year regarding why and how Mozilla is building Persona.
> > If you'd like some more background, that video [0] is worth a look.
> > 
> > Let's pull this discussion up a level:
> > 
> > It sounds like many people (Jesus, Donald, Toshio, Barry, Tres,
> > Dirkjan, etc.) are interested in seeing Persona on Python.org
> > properties, and most of the objections coming from a place of
> > "Persona hasn't gone viral, what if this is wasted effort?"
> > 
> > We can tackle that from two angles:
> > 
> > 1. Dirkjan and I are willing to do the work to make this happen if
> > someone from python-devel is willing to guide us through the
> > contributor process for these systems.

Thanks.

I'm one of the people with admin access to the bug tracker (I haven't
done much maint lately, though, Ezio has done the most).  There is
information on setting up a replica of our production system here:

https://wiki.python.org/moin/TrackerDevelopment

If you want to start hacking on a solution, the first step would be to
spin up a test setup.

If you propose a patch, either I or Ezio should be able to find the time
to review and apply it, if you also commit to maintaining it ;)

Tracker specific discussion happens on the tracker-discuss mailing list,
by the way (very low traffic).

> > 2. There's a seamless migration path away from Persona if we fail:
> > fall back to the pre-existing traditional email/password system
> > using the same email addresses that Persona had previously been in
> > charge of verifying.

Roundup uses database-derived numeric IDs.  An email is associated with
each account, but does not participate in authentication or authorization
after initial signup.  (Except for the email interface...but that is a
separate story and you shouldn't need to address that).

> > So let's do this. The open web deserves better than just Google+,
> > Facebook, or Passwords, and visible support from the Python
> > community would be a huge step toward answering the chicken-and-egg
> > objections raised in this thread.
> > 
> > At your service,
> > -Callahad
> > 
> > PS: Freeform OpenID has utterly failed as a user-empowering
> > authentication system, and the protocol itself is rapidly being
> > supplanted by vendor-specific OAuth[1] systems. If we want to ensure
> > that "you *can* (not *must*) use free and open services to access
> > our resources," then we must provide an option to use something akin
> > to Persona.

IMO, single signon is overrated.  Especially if one prefers not to make
it easy for various accounts to be automatically associated with one
another by various entities who shall remain nameless but have been in
the news a lot lately :)

--David
___
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] Offtopic: OpenID Providers

[R. David Murray]

On Fri, 06 Sep 2013 15:17:12 -0400, Donald Stufft  wrote:
> On Sep 6, 2013, at 3:11 PM, "R. David Murray"  wrote:
> 
> > IMO, single signon is overrated.  Especially if one prefers not to make
> > it easy for various accounts to be automatically associated with one
> > another by various entities who shall remain nameless but have been in
> > the news a lot lately :)
> 
> If I recall Persona doesn't leak this data like OpenID does, but
> perhaps Dan can speak to that better than I can.

Note that I said that single signon *itself* was overrated.  If you use
the same token to authenticate to multiple sites (and here the 'token'
is the email address) then your identities on those sites are ipso facto
associated with each other.  *If* that email address is also never
leaked (never displayed, even to other signed on users, all communication
with the site encrypted), then you only have to worry if the
sites exchange information about their accounts, or if the government
comes knocking on their doors

Yes, I'm paranoid.  That doesn't mean they aren't listening.

That said, sometimes you *want* identities to be associated, so I'm not
saying Persona is a bad thing.  Just that single signon is overrated.

--David
___
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] unicodedata module is out of date

[MRAB]

On 06/09/2013 10:54, Andrew Miller wrote:

The unicodedata module only contains data up to Unicode 5.2 (October
2009), so attempting to reference any character from a later version e.g:

unicodedata.lookup("TURKISH LIRA SIGN")

results in a KeyError.

Also, it seems to be limited to properties in the UnicodeData.txt file
and does not contain any data from the other files from the Unicode
Character Database (the perl library Unicode::UCD is far more complete).

Are there any plans to update this module to the latest Unicode version
(6.2, with 6.3 being released shortly), or is there another module that
provides more up to date information?

Which version of Python are you talking about? Python 3.3 uses Unicode 
version 6.1.

___
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] DTRACE support

[Xavier Morel]

On 2013-09-06, at 19:05 , Antoine Pitrou wrote:

> On Fri, 06 Sep 2013 18:14:26 +0200
> Jesus Cea  wrote:
>> 
>>> Right now, I agree with Charles-François: your patch is too
>>> intrusive.
>> 
>> It is intrusive. Yes. I think it must be, by its own nature. Probably
>> room for improvement and code transparency. But... are Python-DEVs
>> interested in the project?. That is the point :)
> 
> Well, I'm not *personally* interested in anything that only addresses
> Solaris, OS X and the like :)

For what it's worth, there's also a linux port and oracle's distro has
dtrace support.

> And, no, it doesn't have to be *that* intrusive. Take a look at Dave
> Malcolm's systemtap patch, which IIRC takes a much more sensible
> approach.

Is there a possibility of compatibility there, using the same
placeholders for a --with-dtrace and --with-systemtap build?

Jesus seems to instrument more points than Dave, but the extra points
could just be defined to nothing in the systemtap implementation.
___
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] DTRACE support

[Guido van Rossum]

I think there are a couple of issues.

- In order for the patch to be acceptable, we'd need someone to take
responsibility for owning and maintaining it for at least several
years. Jesus, are you willing to commit to this?

- I think it's not all that important whether any core developer would
want to use this for themselves; it's enough if it's useful for others
to have this, and it's clear that at least *some* users really like
this. Different people like different tools, and that's fine.

- There are good reasons (e.g. standardizing a set of probes) for
having a somewhat supported version around.

- Since this *has* to be done in the form of a patch plus a new
configure option, an externally-maintained patch is awkward at least,
and likely to be continually out of date -- this is not something that
you can just as easily put on PyPI as the recommended 3rd party
solution.


- So I'm personally inclined to say "yes, Jesus, if you are willing to
maintain this code (while it is in the core) for several more years,
please invest more of your time, and, assuming you can satisfy the
code reviewers' feedback, we want to accept this in the core,
hopefully in 3.4 if you get it in an acceptable state before 3.4 beta
1 is released."

On Fri, Sep 6, 2013 at 10:12 AM, Charles-François Natali
 wrote:
>> The main value of DTrace is systemwide observability. You can see
>> something "strange" at kernel level and trace it to a particular line
>> of code in a random Python script. There is no other tool that can do
>> that. You have complete transversal observability of ALL the code
>> running in your computer, kernel or usermode, clean reports with
>> threads, etc.
>
> Don't get me wrong, I'm not saying DTrace is useless.
> I'm just saying that, as far as I'm concerned, I've never had any
> trouble debugging/tunning a Python script with non-intrusive tools
> (strace, gdb, valgrind, and oprofile for profiling). Of course, this
> includes analysing bug reports.
>
>> Maybe the biggest objection would be that most python-devs are running
>> Linux, and you don't have dtrace support on linux unless you are
>> running Oracle distribution. But world is larger than linux, and there
>> are some efforts to port DTrace to Linux itself. DTrace is available
>> on Solaris and derivatives, MacOS X and FreeBSD.
>
> That's true, I might have a different opinion if I used Solaris. But
> that's not the case, so te me, the cognitive overhead incurred by this
> large patch isn't worth it.
>
> So I'm -1, but that's a personal opinion :-)
>
> cf
> ___
> 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] Details of "import lock" in 3.3

[Antoine Pitrou]

Le Fri, 06 Sep 2013 17:08:28 +0200,
Jesus Cea  a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> With importlib and other recent changes, what are the current details
> of "import lock"?. That is, the lock/locks held when Python code does
> "import", specially in the case of multithreading. Is that documented
> anywhere?

Quick summary here:
http://docs.python.org/3/whatsnew/3.3.html#a-finer-grained-import-lock

Otherwise, I'm afraid the source code has the most information, e.g.:
http://hg.python.org/cpython/file/1d88d04aade2/Lib/importlib/_bootstrap.py#l124

Regards

Antoine.


___
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] when to fix cross-version bugs?

[Ethan Furman]

On 09/06/2013 07:51 AM, Ethan Furman wrote:


What guidelines determine when a bug is fixed in previous versions?


On 09/06/2013 08:29 AM, Brian Curtin wrote:


If it's a bug in that version and the version is accepting bug fixes,
i.e., not in security mode, go for it. This includes crossing the 2/3
boundary if applicable.


On 09/06/2013 08:31 AM, R. David Murray wrote:


The basic guideline is: we try very hard not to break currently working
code in a maintenance release.  Making that decision very much depends on
the details of each individual case.

[so] it probably doesn't have much positive impact if it does get
backported, so is it worth the (small) chance of breaking someone's code?


And they say never go to the elves for advice!  ;)

--
~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] Offtopic: OpenID Providers

[Donald Stufft]

On Sep 6, 2013, at 1:22 PM, Dan Callahan  wrote:

> On 9/5/13 12:31 PM, Jesus Cea wrote:
>> I have big hopes for Mozilla Persona, looking forward
>> Python infrastructure support :).
> 
> Hi, I'm the project lead on Persona signin, and I spoke at PyCon earlier this 
> year regarding why and how Mozilla is building Persona. If you'd like some 
> more background, that video [0] is worth a look.
> 
> Let's pull this discussion up a level:
> 
> It sounds like many people (Jesus, Donald, Toshio, Barry, Tres, Dirkjan, 
> etc.) are interested in seeing Persona on Python.org properties, and most of 
> the objections coming from a place of "Persona hasn't gone viral, what if 
> this is wasted effort?"
> 
> We can tackle that from two angles:
> 
> 1. Dirkjan and I are willing to do the work to make this happen if someone 
> from python-devel is willing to guide us through the contributor process for 
> these systems.

FWIW I'm a maintainer of PyPI and I do plan on enabling Persona there. Mostly 
blocked because I want to focus my PyPI efforts on the "next gen" code base 
instead.

> 
> 2. There's a seamless migration path away from Persona if we fail: fall back 
> to the pre-existing traditional email/password system using the same email 
> addresses that Persona had previously been in charge of verifying.
> 
> So let's do this. The open web deserves better than just Google+, Facebook, 
> or Passwords, and visible support from the Python community would be a huge 
> step toward answering the chicken-and-egg objections raised in this thread.
> 
> At your service,
> -Callahad
> 
> PS: Freeform OpenID has utterly failed as a user-empowering authentication 
> system, and the protocol itself is rapidly being supplanted by 
> vendor-specific OAuth[1] systems. If we want to ensure that "you *can* (not 
> *must*) use free and open services to access our resources," then we must 
> provide an option to use something akin to Persona.
> 
> [0]: http://pyvideo.org/video/1764
> 
> [1]: "Google's OpenID service is being replaced by Login with OAuth 2.0." 
> https://developers.google.com/accounts/docs/GettingStarted
> 
> ___
> 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/donald%40stufft.io


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Offtopic: OpenID Providers

[Donald Stufft]

On Sep 6, 2013, at 3:34 PM, "R. David Murray"  wrote:

> On Fri, 06 Sep 2013 15:17:12 -0400, Donald Stufft  wrote:
>> On Sep 6, 2013, at 3:11 PM, "R. David Murray"  wrote:
>> 
>>> IMO, single signon is overrated.  Especially if one prefers not to make
>>> it easy for various accounts to be automatically associated with one
>>> another by various entities who shall remain nameless but have been in
>>> the news a lot lately :)
>> 
>> If I recall Persona doesn't leak this data like OpenID does, but
>> perhaps Dan can speak to that better than I can.
> 
> Note that I said that single signon *itself* was overrated.  If you use
> the same token to authenticate to multiple sites (and here the 'token'
> is the email address) then your identities on those sites are ipso facto
> associated with each other.  *If* that email address is also never
> leaked (never displayed, even to other signed on users, all communication
> with the site encrypted), then you only have to worry if the
> sites exchange information about their accounts, or if the government
> comes knocking on their doors
> 
> Yes, I'm paranoid.  That doesn't mean they aren't listening.
> 
> That said, sometimes you *want* identities to be associated, so I'm not
> saying Persona is a bad thing.  Just that single signon is overrated.

Well that's fine to have that opinion but I think you're under estimating just
how easy it is to link two disparate accounts especially if you have the
cooperation (willing or otherwise) of the site operators. I've personally
seen Google do some particularly amazing connections between accounts
that I don't believe using the same authentication token is going to make
that any easier or harder for them.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] DTRACE support

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 20:33, Antoine Pitrou wrote:
> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea  wrote:
>> 
>> It is intrusive. Yes. I think it must be, by its own nature.
>> Probably room for improvement and code transparency. But... are
>> Python-DEVs interested in the project?. That is the point :)
> 
> As a concrete data point: - here are Dave's modifications to
> ceval.c for systemtap: 
> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here
> are your modifications to ceval.c for dtrace: 
> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c

Unfair, because that code is not doing the same thing.

Most of the extra complexity is there to deal with DTRACE ability to
provide meaningful stackframes, with Python code instead of CPython
evaluation loop. This is kind of magical.

Look at this:

""
[root@stargate-host /]# ps -lAf|grep -i correo
 0 S   correo  1371 1   0  40 20? 277063?   Jul 29
?  90:43 /usr/local/bin/python /export/home/
 0 S root 20397 20373   0  40 20?   1294? 05:18:16
pts/12  0:00 grep -i correo

[root@stargate-host /]# dtrace -n 'python1371:::function-entry
{jstack();}'

  5   3164 PyEval_EvalFrameEx:function-entry
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x89a
[ /usr/local/lib/python2.7/logging/__init__.py:1332
(isEnabledFor) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /usr/local/lib/python2.7/logging/__init__.py:1202
(log) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x59ae
[ /home/correo/durus/connection.py:483 (shrink) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /home/correo/durus/connection.py:225 (shrink_cache) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /home/correo/durus/connection.py:303 (commit2) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /home/correo/durus/connection.py:261 (commit) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /export/home/correo/lmtp.py:191 (_monitor) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x59ae
[ /export/home/correo/lmtp.py:125 (process_vacation2) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x59ae
[ /export/home/correo/lmtp.py:138 (process_vacation) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`function_call+0x192
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x2b94
[ /usr/local/lib/python2.7/threading.py: ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`function_call+0xa4
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`instancemethod_call+0xa1
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`PyEval_CallObjectWithKeywords+0x58
  libpython2.7.so.1.0`t_bootstrap+0x52
  libc.so.1`_thr_setup+0x4e
  libc.so.1`_lwp_start

^C
"""

Lets say I want to know about what codepaths are hitting the OS "sync"
features, so I do this:

"""
[root@stargate-host /]# dtrace -n
'syscall::fdsync:entry/pid==1371/{jstack();}'
dtrace: description 'syscall::fdsync:entry' matched 1 probe

CPU IDFUNCTION:NAME
  3  58344 fdsync:entry
  libc.so.1`__fdsync+0x15
  libdb-6.0.so`__os_fsync+0x91
  libdb-6.0.so`__log_flush_int+0x685
  libdb-6.0.so`__log_flush+0x6a
  libdb-6.0.so`__log_flush_pp+0x121
  _pybsddb.so`DBEnv_log_flush+0x39
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6992
[
/export/home/correo/durus-berkeleydbstorage/berkeleydb_storage.py:918
(flush) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /export/home/correo/lmtp.py:1005 (lmtp2) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x6231
[ /export/home/correo/lmtp.py:763 (lmtp) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`function_call+0x192
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x2b94
[ /export/home/correo/lmtp.py:214
(_ignore_socket_errors) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7b4
  libpython2.7.so.1.0`function_call+0x192
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`

Re: [Python-Dev] DTRACE support

[Xavier Morel]

On 2013-09-07, at 05:40 , Jesus Cea wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 06/09/13 20:33, Antoine Pitrou wrote:
>> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea  wrote:
>>> 
>>> It is intrusive. Yes. I think it must be, by its own nature.
>>> Probably room for improvement and code transparency. But... are
>>> Python-DEVs interested in the project?. That is the point :)
>> 
>> As a concrete data point: - here are Dave's modifications to
>> ceval.c for systemtap: 
>> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here
>> are your modifications to ceval.c for dtrace: 
>> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c
> 
> Unfair, because that code is not doing the same thing.
> 
> Most of the extra complexity is there to deal with DTRACE ability to
> provide meaningful stackframes, with Python code instead of CPython
> evaluation loop. This is kind of magical.

Antoine will correct me if I'm wrong, but I believe his point is less
about the complexity of dtrace provision and more about how much of it
lives in ceval.c: the systemtap provision also takes quite a bit of
code, but almost all of that code is extracted into a separate file and
only a pair of calls live in ceval.c

You patch, because it adds quite a bit of complexity to ceval.c, makes
reading it significantly more difficult (especially for people who don't
care for probe implementations). Dave's more or less doesn't change the
complexity of that file (people who don't care for probes don't have to
follow the macros to know what they do).
___
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