Re: [Python-Dev] Continuing 2.x

[Stephen J. Turnbull]

Casey Duncan writes:

 > However there are many many more users of Python 2.x than Python
 > 3.x.  Many may never upgrade for the life of these projects,
 > because if it ain't broke, why fix it? It doesn't matter how much
 > better Python 3 is than Python 2. It isn't better enough.

And the "don't fix what ain't broke" people are well supported, by
explicit policy and by the personal dedication of developers like
Victor Stinner.

 > In this regard the existence of Python 3 is a disadvantage, not an
 > advantage for my new code, regardless of how much better a language
 > or dev environment it may be.

You mean, at this very instant.  Pay now, profit later is the
definition of "investment."  In the past, while I'm sure you worked
real hard, you didn't have to pay the price of the *community's*
investment because you were free to start new projects in the way best
fitted to current features.  Now, with a large codebase to maintain
and extend, you have to share the community's costs by either living
with Python 2, which won't improve from now on, or shifting to Python
3, which entails big porting costs for many projects.[1]  Or you can
participate in a new project to fork from python.org and continue
development of Python 2.

You have a wealth of choice there.  The problem[2] is that you're not
getting a free ride on the fast track this time.  Well, that party was
nice while it lasted, but now it's over.  The next party is going to
be at the Python 3 Lounge, and you're invited.  Sure, you gotta get up
and go to work tomorrow, but Friday's comin'!

Footnotes: 
[1]  But I can't say it's obvious that they're huge on average.
There's clearly a lot of variance in porting costs.

[2]  This is a community problem; it's not something you did to
yourself.  But it's also been judged unavoidable if Python is to
continue to grow.

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

Re: [Python-Dev] Regular scheduled releases (was: Continuing 2.x)

[Dirkjan Ochtman]

On Sat, Oct 30, 2010 at 05:22, Nick Coghlan  wrote:
> Ultimately, the frequency of releases comes down to the burden on the
> release manager and the folks that build the binary installers. Any
> given RM is usually only responsible for one or two branches, but the
> same two people (Martin and Ronald) typically build the Windows and
> Mac OS X binaries for all of them. So if you add 2.6 and 3.1 together,
> as well as the releases for 2.7 and 3.2 development, I think you'll
> find releases happening a lot more often than an average of 1 every 4
> months.

Right, the effort of those people is obviously the limiting factor
here. Automating builds sounds like a good step forward. What are the
sticky bits here? Martin, Ronald, how much of the process is not
automated, and why is automating hard?

Cheers,

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

Re: [Python-Dev] Regular scheduled releases

[Martin v. Löwis]

> Right, the effort of those people is obviously the limiting factor
> here. Automating builds sounds like a good step forward. What are the
> sticky bits here? Martin, Ronald, how much of the process is not
> automated, and why is automating hard?

I don't feel like producing a complete list of build steps; the entire
process takes about four hours.
The steps that are difficult to automate are:
- code signing
- testing the resulting installer
- uploading

However, in a significant number of releases, some of the build steps
failed, so it requires some investigation to find the source of the
problem.

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

Re: [Python-Dev] r85960 - python/branches/py3k/Lib/test/test_mailbox.py

[Antoine Pitrou]

On Sat, 30 Oct 2010 02:13:01 +0200 (CEST)
brett.cannon  wrote:
> Author: brett.cannon
> Date: Sat Oct 30 02:13:00 2010
> New Revision: 85960
> 
> Log:
> Silence some ResourceWarning in test_mailbox by using file context managers.

Unfortunately, these file-like objects don't support the context
management protocol:

==
ERROR: test_get_file (test.test_mailbox.TestMaildir)
--
Traceback (most recent call last):
  File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__

==
ERROR: test_get_file (test.test_mailbox.TestMbox)
--
Traceback (most recent call last):
  File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__

==
ERROR: test_get_file (test.test_mailbox.TestMMDF)
--
Traceback (most recent call last):
  File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__

==
ERROR: test_get_file (test.test_mailbox.TestMH)
--
Traceback (most recent call last):
  File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__




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

Re: [Python-Dev] Regular scheduled releases

[Dirkjan Ochtman]

On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis"  wrote:
> I don't feel like producing a complete list of build steps; the entire
> process takes about four hours.

So is most of this scripted, or is there just a process in your head?

> The steps that are difficult to automate are:
> - code signing
> - testing the resulting installer
> - uploading

Why are those steps difficult to automate? I'd think that uploading is
just some ftp commands. Signing might be a thing because you don't
want the keys distributed. Testing the resulting installer could
probably be automated in part, and people could still download the
nightlies to do more testing.

> However, in a significant number of releases, some of the build steps
> failed, so it requires some investigation to find the source of the
> problem.

Well, sure, but if we do continuous builds we find failures like that sooner.

Cheers,

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

Re: [Python-Dev] Cleaning-up the new unittest API

[Antoine Pitrou]

On Fri, 29 Oct 2010 20:14:27 -0700
Raymond Hettinger  wrote:
> 
> I would like to simplify and clean-up the API for the unittest module
> by de-documenting assertSetEqual(), assertDictEqual(),
> assertListEqual, and assertTupleEqual().

+1 from me.

Regards

Antoine.


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

Re: [Python-Dev] Regular scheduled releases

[Martin v. Löwis]

Am 30.10.2010 14:29, schrieb Dirkjan Ochtman:
> On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis"  wrote:
>> I don't feel like producing a complete list of build steps; the entire
>> process takes about four hours.
> 
> So is most of this scripted, or is there just a process in your head?

Define "most". There hundreds of commands that run automatically (like
all compiler invocations). But still, there are about 20 steps that are
in my head, some written down in plain English.

But yes, "most" of the steps (by sheer number) are automated.

> Why are those steps difficult to automate? I'd think that uploading is
> just some ftp commands.

No, it's ssh, and you need access to the right key. More importantly,
it's editing content.ht, to update the links, compute and copy the
md5sums and size, and svn add the GPG signatures.

It *could* be automated, I suppose. It just isn't, and it would take
quite some time to automate it.

> Testing the resulting installer could
> probably be automated in part, and people could still download the
> nightlies to do more testing.

People will never ever test nightly builds. Been there, done that.
Instead, the nightly build process will break, and nobody will fix
it for months (or even complain, for that matter).

I also doubt that the installer could be automatically tested with
reasonable effort.

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

Re: [Python-Dev] r85960 - python/branches/py3k/Lib/test/test_mailbox.py

[Georg Brandl]

Am 30.10.2010 12:12, schrieb Antoine Pitrou:
> On Sat, 30 Oct 2010 02:13:01 +0200 (CEST)
> brett.cannon  wrote:
>> Author: brett.cannon
>> Date: Sat Oct 30 02:13:00 2010
>> New Revision: 85960
>> 
>> Log:
>> Silence some ResourceWarning in test_mailbox by using file context managers.
> 
> Unfortunately, these file-like objects don't support the context
> management protocol

Should be fixed in r85979.  Do we want Mailboxes themselves to be
context managers?

Georg
-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

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

Re: [Python-Dev] [Python-checkins] r85934 - in python/branches/py3k: Misc/NEWS Modules/socketmodule.c

[Hirokazu Yamamoto]

On 2010/10/30 3:20, martin.v.loewis wrote:

Modified: python/branches/py3k/Modules/socketmodule.c
==
--- python/branches/py3k/Modules/socketmodule.c (original)
+++ python/branches/py3k/Modules/socketmodule.c Fri Oct 29 20:20:08 2010
@@ -3093,6 +3093,27 @@
  static PyObject *
  socket_gethostname(PyObject *self, PyObject *unused)
  {
+#ifdef MS_WINDOWS
+/* Don't use winsock's gethostname, as this returns the ANSI
+   version of the hostname, whereas we need a Unicode string.
+   Otherwise, gethostname apparently also returns the DNS name. */
+wchar_t buf[MAX_COMPUTERNAME_LENGTH];
+DWORD size = sizeof(buf);
+if (!GetComputerNameExW(ComputerNamePhysicalDnsHostname, buf,&size)) {
+if (GetLastError() == ERROR_MORE_DATA) {
+/* MSDN says this may occur "because DNS allows longer names */
+PyObject *result = PyUnicode_FromUnicode(NULL, size);
+if (!result)
+return NULL;
+if (GetComputerName(ComputerNamePhysicalDnsHostname,
+PyUnicode_AS_UNICODE(result),
+size+1))
+return result;
+}
+return PyErr_SetExcFromWindowsErr(PyExc_WindowsError, GetLastError());
+}
+return PyUnicode_FromUnicode(buf, size);
+#else
  char buf[1024];
  int res;
  Py_BEGIN_ALLOW_THREADS
@@ -3102,6 +3123,7 @@
  return set_error();
  buf[sizeof buf - 1] = '\0';
  return PyUnicode_FromString(buf);
+#endif
  }

  PyDoc_STRVAR(gethostname_doc,
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins



I think size should be in TCHARs, not in bytes. (MSDN says so)
And GetComputerName's signature differs from MSDN. (Maybe should
use GetComputerNameExW again?)

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

Re: [Python-Dev] Cleaning-up the new unittest API

[Michael Foord]

On 30/10/2010 02:41, Steven D'Aprano wrote:

Raymond Hettinger wrote:

The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book). I 
think we can improve learnability by focusing on the most important 
parts of the API.


I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(), assertDictEqual(),
assertListEqual, and assertTupleEqual().


While you're at it, what do you think of assertAlmostEqual? Is there a 
use-case for it as it exists now?


As I see it, it suffers from a number of problems:

(1) Comparing floats for equality to some number of decimal places is 
rarely (never?) the right way to do it. Comparison to some number of 
significant figures would be better. Specifying an absolute or 
relative error would be better still.




I agree, comparing floats to a specific number of decimal places has 
almost always been useless to me. What would be nice would be a 'delta' 
keyword argument allowing you to specify a difference instead. That 
could also allow you to compare non-numeric objects like times as well.


Now where are the keys to that time machine...

http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertAlmostEqual

All the best,

Michael Foord

(2) This leads people to write the wrong test, because 
assertAlmostEqual exists and is easy to use, while the right test is 
tricky and requires better understanding of floating point issues.


Example: I recently wrote tests using assertAlmostEqual where I 
specified places=12, because my code should have been accurate to 12 
significant figures. Worked fine for small floating point, but when I 
started testing values of the order of 1, my tests started 
failing, because although it was correct to > 12 significant figures, 
five of those figures were not decimal places.


(3) In the rare case that mere rounding is the right way to compare 
for approximate equality, assertAlmostEqual doesn't save you much: a 
handful of characters, that's about all.


self.assertAlmostEqual(x, y, places=n)

vs.

self.assertEqual(round(x, n), round(y, n))

(Specifying the number of decimal places is keyword-only in 3.1. To 
me, that seems to be a gratuitous change from 2.x, where it could be 
specified as a positional argument.)







--
http://www.voidspace.org.uk/

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

[Python-Dev] PyMem_MALLOC vs PyMem_Malloc

[Hirokazu Yamamoto]

Hello. I found several codes using PyMem_Free to free
allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)

Is it safe?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleaning-up the new unittest API

[R. David Murray]

On Sat, 30 Oct 2010 14:51:28 +0200, Antoine Pitrou  wrote:
> On Fri, 29 Oct 2010 20:14:27 -0700
> Raymond Hettinger  wrote:
> > 
> > I would like to simplify and clean-up the API for the unittest module
> > by de-documenting assertSetEqual(), assertDictEqual(),
> > assertListEqual, and assertTupleEqual().
> 
> +1 from me.

I don't disagree with this simplification, but given that you all want
to pare down the unittest API, I'd be interested in your opinions on
issue 10164.  Because the assertBytesEqual method takes an optional
argument, it seems like it would need to be documented, even though
it would in a lot of cases just be used through assertEqual.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleaning-up the new unittest API

[Antoine Pitrou]

On Sat, 30 Oct 2010 12:02:27 -0400
"R. David Murray"  wrote:
> 
> I don't disagree with this simplification, but given that you all want
> to pare down the unittest API, I'd be interested in your opinions on
> issue 10164.  Because the assertBytesEqual method takes an optional
> argument, it seems like it would need to be documented, even though
> it would in a lot of cases just be used through assertEqual.

The optional argument doesn't look very useful. I imagine there are
plenty of special cases where you could need custom splitting of
bytestrings on a given byte, a regexp pattern, or along some fixed
chunk length, but they are special cases.

Regards

Antoine.


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

Re: [Python-Dev] PyMem_MALLOC vs PyMem_Malloc

[M.-A. Lemburg]

Hirokazu Yamamoto wrote:
> Hello. I found several codes using PyMem_Free to free
> allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
> 
> Is it safe?

Within the interpreter: yes.

In extensions: depends on the platform, but probably not.

The macros provide faster access to the C lib malloc calls.

The functions need to be used in extensions in case the interpreter will
free the resource or the extension wants to free an interpreter
allocated resource. They provide access to the malloc calls
used by the interpreter, which may operate on a different heap
than the extensions.

Within an extension the macros use the extension heap.

A subtle, but important difference.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 30 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyMem_MALLOC vs PyMem_Malloc

[M.-A. Lemburg]

M.-A. Lemburg wrote:
> Hirokazu Yamamoto wrote:
>> Hello. I found several codes using PyMem_Free to free
>> allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
>>
>> Is it safe?
> 
> Within the interpreter: yes.
>
> In extensions: depends on the platform, but probably not.
> 
> The macros provide faster access to the C lib malloc calls.
> 
> The functions need to be used in extensions in case the interpreter will
> free the resource or the extension wants to free an interpreter
> allocated resource. They provide access to the malloc calls
> used by the interpreter, which may operate on a different heap
> than the extensions.
> 
> Within an extension the macros use the extension heap.
> 
> A subtle, but important difference.

BTW: If you were referring to extensions using PyMem_Free()
to deallocate memory allocated in the interpreter using
PyMem_MALLOC(), then that's exactly how things should be
done.

I was referring to use of the two mentioned APIs within
an extension.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 30 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleaning-up the new unittest API

[R. David Murray]

On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou  wrote:
> On Sat, 30 Oct 2010 12:02:27 -0400
> "R. David Murray"  wrote:
> > 
> > I don't disagree with this simplification, but given that you all want
> > to pare down the unittest API, I'd be interested in your opinions on
> > issue 10164.  Because the assertBytesEqual method takes an optional
> > argument, it seems like it would need to be documented, even though
> > it would in a lot of cases just be used through assertEqual.
> 
> The optional argument doesn't look very useful. I imagine there are
> plenty of special cases where you could need custom splitting of
> bytestrings on a given byte, a regexp pattern, or along some fixed
> chunk length, but they are special cases.

Well, I have a specific special case I need it for:  comparing byte
strings that are wire-format email messages.  Considering how much of
a pain it was to get right, I'd hate to see people have to reimplement
the guts of it for each special case.  Maybe a 'make_chunks' argument
that takes a function that returns a list?

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleaning-up the new unittest API

[Antoine Pitrou]

On Sat, 30 Oct 2010 14:24:10 -0400
"R. David Murray"  wrote:

> On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou  
> wrote:
> > On Sat, 30 Oct 2010 12:02:27 -0400
> > "R. David Murray"  wrote:
> > > 
> > > I don't disagree with this simplification, but given that you all want
> > > to pare down the unittest API, I'd be interested in your opinions on
> > > issue 10164.  Because the assertBytesEqual method takes an optional
> > > argument, it seems like it would need to be documented, even though
> > > it would in a lot of cases just be used through assertEqual.
> > 
> > The optional argument doesn't look very useful. I imagine there are
> > plenty of special cases where you could need custom splitting of
> > bytestrings on a given byte, a regexp pattern, or along some fixed
> > chunk length, but they are special cases.
> 
> Well, I have a specific special case I need it for:  comparing byte
> strings that are wire-format email messages.  Considering how much of
> a pain it was to get right, I'd hate to see people have to reimplement
> the guts of it for each special case.  Maybe a 'make_chunks' argument
> that takes a function that returns a list?

Well, I was hoping that we don't need to make assertBytesEqual a public
API ;)

Regards

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

Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib

[Jack Diederich]

On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon  wrote:
> For those of you who have not noticed, Antoine committed a patch that
> raises a ResourceWarning under a pydebug build if a file or socket is
> closed through garbage collection instead of being explicitly closed.

Just yesterday I discovered /proc//fd/ which is a list
of open file descriptors for your PID on *nix and includes all open
files, pipes, and sockets.  Very handy, I filed some tickets about
company internal libs that were opening file handles as a side effect
of import (logging mostly).  I tried to provoke standard python
imports (non-test) to leave some open handles and came up empty.

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

Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib

[Glyph Lefkowitz]

On Oct 30, 2010, at 2:39 PM, Jack Diederich wrote:

> On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon  wrote:
>> For those of you who have not noticed, Antoine committed a patch that
>> raises a ResourceWarning under a pydebug build if a file or socket is
>> closed through garbage collection instead of being explicitly closed.
> 
> Just yesterday I discovered /proc//fd/ which is a list
> of open file descriptors for your PID on *nix and includes all open
> files, pipes, and sockets.  Very handy, I filed some tickets about
> company internal libs that were opening file handles as a side effect
> of import (logging mostly).  I tried to provoke standard python
> imports (non-test) to leave some open handles and came up empty.

That path (and anything below /proc, really) is a list of open file descriptors 
specifically on Linux, not "*nix".  Also on linux, you can avoid "" by just doing "/proc/self".

A more portable (albeit not standard) path for "what file descriptors do I have 
open" is /dev/fd/.  This is supported via a symlink to /proc/self on all the 
Linuxes I've tested on.  There's no portable standard equivalent for 
not-yourself processes that I'm aware of, though.

See more discussion here: .

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

Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib

[Jack Diederich]

On Sat, Oct 30, 2010 at 3:06 PM, Glyph Lefkowitz
 wrote:
>
> On Oct 30, 2010, at 2:39 PM, Jack Diederich wrote:
>
> On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon  wrote:
>
> For those of you who have not noticed, Antoine committed a patch that
>
> raises a ResourceWarning under a pydebug build if a file or socket is
>
> closed through garbage collection instead of being explicitly closed.
>
> Just yesterday I discovered /proc//fd/ which is a list
> of open file descriptors for your PID on *nix and includes all open
> files, pipes, and sockets.  Very handy, I filed some tickets about
> company internal libs that were opening file handles as a side effect
> of import (logging mostly).  I tried to provoke standard python
> imports (non-test) to leave some open handles and came up empty.
>
> That path (and anything below /proc, really) is a list of open file
> descriptors specifically on Linux, not "*nix".  Also on linux, you can avoid
> "" by just doing "/proc/self".

I was happy to find out that the /proc system came from Plan9 because
I always thought Plan9 was dead water.  But in this particular case
Plan9 outdid System7 in the the realm of "everything is a file" by
making everything a file.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r85934 - in python/branches/py3k: Misc/NEWS Modules/socketmodule.c

[Martin v. Löwis]

> I think size should be in TCHARs, not in bytes. (MSDN says so)
> And GetComputerName's signature differs from MSDN. (Maybe should
> use GetComputerNameExW again?)

You are right. So how about this patch?

Index: Modules/socketmodule.c
===
--- Modules/socketmodule.c  (Revision 85983)
+++ Modules/socketmodule.c  (Arbeitskopie)
@@ -3098,16 +3098,16 @@
version of the hostname, whereas we need a Unicode string.
Otherwise, gethostname apparently also returns the DNS name. */
 wchar_t buf[MAX_COMPUTERNAME_LENGTH];
-DWORD size = sizeof(buf);
+DWORD size = sizeof(buf)/sizeof(wchar_t);
 if (!GetComputerNameExW(ComputerNamePhysicalDnsHostname, buf, &size)) {
 if (GetLastError() == ERROR_MORE_DATA) {
 /* MSDN says this may occur "because DNS allows longer names */
 PyObject *result = PyUnicode_FromUnicode(NULL, size);
 if (!result)
 return NULL;
-if (GetComputerName(ComputerNamePhysicalDnsHostname,
-PyUnicode_AS_UNICODE(result),
-size+1))
+if (GetComputerNameExW(ComputerNamePhysicalDnsHostname,
+   PyUnicode_AS_UNICODE(result),
+   size+1))
 return result;
 Py_DECREF(result);
 }

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

Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib

[Martin v. Löwis]

> I was happy to find out that the /proc system came from Plan9 because
> I always thought Plan9 was dead water.  But in this particular case
> Plan9 outdid System7 in the the realm of "everything is a file" by
> making everything a file.

However, on Plan 9, /proc//fd is not a directory, but a regular text
file. There would be one line in this file per open file descriptor,
see

http://plan9.bell-labs.com/magic/man2html/3/proc

Also notice that the /proc filesystem did *not* come from Plan 9
originally, see

http://en.wikipedia.org/wiki/Procfs

It originally came from Unix V8, in 1984. In that version, each entry
in /proc was a file, essentially giving access to the process'
address space. Supposedly, it was still possible to find out the
list of open files using that interface, see

http://man.cat-v.org/unix_8th/4/proc

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

Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib

[Bobby Impollonia]

On Sat, Oct 30, 2010 at 12:06 PM, Glyph Lefkowitz
 wrote:
> That path (and anything below /proc, really) is a list of open file
> descriptors specifically on Linux, not "*nix".  Also on linux, you can avoid
> "" by just doing "/proc/self".
> A more portable (albeit not standard) path for "what file descriptors do I
> have open" is /dev/fd/.  This is supported via a symlink to /proc/self on
> all the Linuxes I've tested on.  There's no portable standard equivalent for
> not-yourself processes that I'm aware of, though.
> See more discussion here: .

lsof(8) is available for Linux, FreeBSD, Mac any many other *nixes:
http://en.wikipedia.org/wiki/Lsof
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Continuing 2.x

[Neil Schemenauer]

I have a specific, easy to implement proposal.  I would like one
more version tag added to the Roundup tracker.  My proposed name is
"Python 2.7+" but I don't care what it is called.

It would be used to tag bug reports and patches that apply only to
the 2.x line and are considered not appropriate for the 2.7.x
release.  In order to keep them out of the way, I suppose they could
be marked as "postponed" and closed.

It's possible that no one will step up to handle these issues and
integrate them into a Python 2.7+ release (official or fork).
However, given the cost to add such a tag, I think it would be a
shame to lose the manpower used to produce such bug reports and
patches.

  Neil

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

Re: [Python-Dev] Continuing 2.x

[Terry Reedy]

On 10/30/2010 6:32 PM, Neil Schemenauer wrote:

I have a specific, easy to implement proposal.  I would like one
more version tag added to the Roundup tracker.  My proposed name is
"Python 2.7+" but I don't care what it is called.


As a tracker gardener, I disagree. I would expect such to cause more 
trouble than it is worth.



It would be used to tag bug reports  and patches that apply only to
the 2.x line and are considered not appropriate for the 2.7.x
release.


Bug reports *are* appropriate.


 In order to keep them out of the way, I suppose they could
be marked as "postponed" and closed.


The few issues that would get such a 2.7+ tag can just as well be marked 
2.7/closed/postponed.



It's possible that no one will step up to handle these issues


Which would make new the version tag YAGNI


--
Terry Jan Reedy

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

Re: [Python-Dev] Regular scheduled releases

[David Bolen]

"Martin v. Löwis"  writes:

> People will never ever test nightly builds. Been there, done that.
> Instead, the nightly build process will break, and nobody will fix
> it for months (or even complain, for that matter).

Certainly seems to be past experience.

I know Martin knows this, but for other readers who may not, my
Windows XP buildbot built nightly windows installers (the basic MSI
package, close but not necessarily a fully signed new release as
Martin makes) starting in September, 2007.  It ran successfully for
about 6 months, at which point it started to fail fairly consistently.
Nobody noticed, and Martin and I finally just shut it down in
December, deciding it wasn't worth the effort to try to fix.

My OSX buildbot has been building nightly DMG images (though again, I
suspect Ronald has a few extra steps beyond what its doing for a full
release) since April.  I'd actually be interested in knowing if anyone
is using them - I suspect perhaps not.

In both cases, getting the process going actually took quite a bit of
effort (even stuff like having to fix the buildbot upload code in the
Windows case), not just on my part, but with the help of Martin and
Ronald.  But without actual use of the result, it's hard to think it
was worth it.  I'm pretty sure my default reaction to a break-down in
the current OSX build process at this point would be to first suggest
disabling it unless there were real users.

-- David

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