Re: [Python-Dev] Decimal news
Thomas Wouters wrote: Unfortunately, that's not how it works :-) If you check something into the trunk, it will be merged into Py3k sooner or later. I may ask the original submitter for assistance if it's incredibly hard to figure out the changes, but so far, I only had to do that with the SSL changes. The decimal changes are being merged as I write this (tests running now.) Is there anything in particular that needs to be done for decimal in Py3k, besides renaming __div__ to __truediv__? If you re-eally need to check something into the trunk that re-eally must not be merged into py3k, but you're afraid it's not going to be obvious to the merger, please record the change as 'merged' using svnmerge merge -M -rrevision. Please take care when picking the revision ;) You can also just email me or someone else you see doing merges, as I doubt this will be a common occurance. I'm getting ready to port my PEP 3101 implementation (str.format() and friends) from py3k back to 2.6. How do I make it obvious that this is something that doesn't need to be ported to py3k? I'm not sure what obvious to the merger means. Is a backported checkin comment good enough? With any luck this will be done with a single checkin to the trunk, and another checkin to py3k so that the implementations can remain identical. I just want to make sure I don't make life more difficult than necessary for the folks doing the very valuable merge process. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Special file nul in Windows and os.stat
Fred Drake wrote: On Oct 24, 2007, at 4:23 PM, Facundo Batista wrote: There (and always talking in windows), the OP says the in Py2.4 os.path.exists(nul) returned True and now in 2.5 returns False. Note that nul is an special file, something like /dev/null. It's special, but in a different way. /dev/null really exists in the Unix filesystem; nul is more magical than that. What's more, it has peers: prn, com1 and others like that. It's even worse than that, because file extensions are ignored in this magical-ness: C:\Documents and Settings\Usertype nul C:\Documents and Settings\Usertype nul.lst C:\Documents and Settings\Usertype foo.lst The system cannot find the file specified. I don't know what the right way to handle these is (I'm no Windows guru, or even regular user), but it's important to realize that the pain of the specialness isn't limited. :-) http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part3/proch17.mspx?mfr=true gives the list as CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NUL; but I can't imagine testing against that list would be the best idea. For example, http://www.microsoft.com/technet/solutionaccelerators/cits/interopmigration/unix/unixbld/unixbld4.mspx adds CLOCK$, among others (although I don't find CLOCK$ to be special, it's rumored to be an NT only thing, and I'm running XP). So I think implementing Facundo's option 2 (test for nul) will not work in the general case for finding special files (don't forget to throw in mixed case names). I hate to think of trying to match Windows' behavior if there are multiple dots in the name. I think I'd leave the current behavior of calling the kernel function, even though it varies based on Windows version (if I'm reading the issue correctly). Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backporting PEP 3101 to 2.6
(I'm posting to python-dev, because this isn't strictly 3.0 related. Hopefully most people read it in addition to python-3000). I'm working on backporting the changes I made for PEP 3101 (Advanced String Formatting) to the trunk, in order to meet the pre-PyCon release date for 2.6a1. I have a few questions about how I should handle str/unicode. 3.0 was pretty easy, because everything was unicode. 1: How should the builtin format() work? It takes 2 parameters, an object o and a string s, and returns o.__format__(s). If s is None, it returns o.__format__(empty_string). In 3.0, the empty string is of course unicode. For 2.6, should I use u'' or ''? 2: In 3.0, object.__format__() is essentially this: class object: def __format__(self, format_spec): return format(str(self), format_spec) In 2.6, I assume it should be the equivalent of: class object: def __format__(self, format_spec): if isinstance(format_spec, str): return format(str(self), format_spec) elif isinstance(format_spec, unicode): return format(unicode(self), format_spec) else: error Does that seem right? 3: Every overridden __format__() method is going to have to check for string or unicode, just like object.__format() does, and return either a string or unicode object, appropriately. I don't see any way around this, but I'd like to hear any thoughts. I guess there aren't all that many __format__ methods that will be implemented, so this might not be a big burden. I'll of course implement the built in ones. Thanks in advance for any insights. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
M.-A. Lemburg wrote: On 2008-01-10 14:31, Eric Smith wrote: (I'm posting to python-dev, because this isn't strictly 3.0 related. Hopefully most people read it in addition to python-3000). I'm working on backporting the changes I made for PEP 3101 (Advanced String Formatting) to the trunk, in order to meet the pre-PyCon release date for 2.6a1. I have a few questions about how I should handle str/unicode. 3.0 was pretty easy, because everything was unicode. Since this is a new feature, why bother with strings at all (even in 2.6) ? Use Unicode throughout and be done with it. I was hoping someone would say that! It would certainly make things much easier. But for my own selfish reasons, I'd like to have str.format() work in 2.6. Other than the issues I raised here, I've already done the vast majority of the work for the code to support either string or unicode. For example, I put most of the implementation in Objects/stringlib, so I can include it either as string or unicode. But I can live with unicode only if that's the consensus. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
Nick Coghlan wrote: Guido van Rossum wrote: For data types whose output uses only ASCII, would it be acceptable if they always returned an 8-bit string and left it up to the caller to convert it to Unicode? This would apply to all numeric types. (The date/time types have a strftime() style API which means the user must be able to specifiy Unicode.) To elaborate on this a bit (and handwaving a lot of important details out of the way) do you mean something like the following for the builtin format?: def format(obj, fmt_spec=None): if fmt_spec is None: fmt_spec='' result = obj.__format__(fmt_spec) if isinstance(fmt_spec, unicode): if isinstance(result, str): result = unicode(result) return result That's the approach I'm taking. The builtin format is the only caller of __format__ that I know of, so it's the only place this would need to be done. ___ 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] Backporting PEP 3101 to 2.6
Steve Holden wrote: Nick Coghlan wrote: To elaborate on this a bit (and handwaving a lot of important details out of the way) do you mean something like the following for the builtin format?: def format(obj, fmt_spec=None): if fmt_spec is None: fmt_spec='' result = obj.__format__(fmt_spec) if isinstance(fmt_spec, unicode): if isinstance(result, str): result = unicode(result) return result Isn't unicode idempotent? Couldn't if isinstance(result, str): result = unicode(result) avoid repeating in Python a test already made in C by re-spelling it as result = unicode(result) or have you hand-waved away important details that mean the test really is required? This code is written in C. It already has a check to verify that the return from __format__ is either str or unicode, and another check that fmt_spec is str or unicode. So doing the conversion only if result is str and fmt_spec is unicode would be a cheap decision. Good catch, though. I wouldn't have thought of it, and there are parts that are written in Python, so maybe I can leverage this elsewhere. Thanks! Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370, open questions
[EMAIL PROTECTED] wrote: discussion of per-user directories on different platforms One of the problems we've encountered over and over again with Combinator is that MacOS has a dual personality. Its personality is not just an issue of framework vs. non-framework build, but a fundamental question of is this platform a UNIX or is it not a UNIX. MacOS isn't the only platform that has this problem. I use cygwin under Windows, and I wish Python (whether or not a cygwin build) would also use ~/.local. On the Mac, our user now has a problem: given that ~/Library/Python/ doesn't follow the /usr or /usr/local style filesystem layout, autotools-based projects will not build their libraries in the right places using a single command-line option. (I guess maybe you could do something with --bindir and --sbindir and --exec-prefix or whatever, I don't know. I tend to get bored and wander off when I have to pass more than 3 options to a configure script.) I guess Windows isn't as bad as MacOS in this case, because there's no standard to follow and conflict with. Everything under whatever directory we choose won't likely match other packages, so we can do whatever we want. Still, I'd prefer something under $HOME. Windows has this problem less because everything has to be done so completely differently. True, except that cygwin tries hard to make it look like Unix. I'd rather Python under Windows really look like Unix, but I'm probably in a minority. And yes, I do share computers (physically and through Terminal Server), so per-user local libraries would be nice. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is anyone porting PyNumber_ToBase to trunk?
In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to do the heavy lifting. If someone is planning on implementing PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess I'll either do it myself, or hack around it. Is this on anyone's To Do list? I don't see it on Brett's spreadsheet at http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg ___ 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] Is anyone porting PyNumber_ToBase to trunk?
Guido van Rossum wrote: On Jan 23, 2008 7:40 AM, Eric Smith [EMAIL PROTECTED] wrote: In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to do the heavy lifting. If someone is planning on implementing PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess I'll either do it myself, or hack around it. Is this on anyone's To Do list? I don't see it on Brett's spreadsheet at http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg I'm sure this is because nobody had thought of this detail until now. Just get started on it. Feel free to add it to the spreadsheet. It's an implementation detail of PEP 3127 (oct() and bin()), which is on the spreadsheet. I guess I'll have to work on oct() and bin() first. The spreadsheet notes a possible __future__ statement requirement for oct(). The PEP doesn't mention this, and I'm not sure I understand the issue. Any clues? ___ 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] trunc()
Guido van Rossum wrote: On Jan 27, 2008 9:26 AM, Andrea Griffini [EMAIL PROTECTED] wrote: Anyway I want just to say that if implicit conversion from float to integer goes away then what happens to formatting conversion ? Removing that too IMO would break a lot of code and it's IMO very difficult to help fixing that. The formatting code could assign specific meanings. I suspect though that it was never meant to be possible to use %d with a float -- it just is one of the artifacts of using implicit conversion, and one not well-thought through. Note: %.0f % 3.99 '4' %d % 3.99 '3' I think the latter is wrong and confusing. format() has the same issue, for the same reason: format(3.9, 'f') '3.90' format(3.9, 'd') '3' I never noticed this before, and it's a definite error. PEP 3101 says the valid types for float are 'eEfFgGn%' and an empty string. I'll remove the integer conversion in the float formatter. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slot for __trunc__
Raymond Hettinger wrote: [GvR] I don't see why. __index__ has a slot because its primary use is to be called from C code, where slots add a slight performance advantage. __trunc__ doesn't get called from C AFAIK. I thought the __trunc__ method only gets called from the C code for the trunc() function which is currently implemented with PyObject_CallMethod(number, __trunc__, ) instead of a fast call to a slot. And if __trunc__ qualifies, what about __format__, which is similar? I'm not pushing for it, I just wonder how the decision is made. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Why is there to Lib/test/test_int.py?
I want to add test cases for int.__format__(), and I went looking for Lib/test/test_int.py. I've added tests into Lib/test/test_long.py, so I assumed there was an int version, but no. Is there any particular reason for that, and are there int tests elsewhere? If not, I'll add test_int.py, but I want to make sure that's the right thing to do. Thanks. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding __format__ to classic classes
When backporting PEP 3101, do we want to add __format__ to classic classes? If so, could someone give me a pointer on how to implement this? I don't see where to hook it up. Thanks. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?
I'm thinking that I need to add a __format__ to the most base old
style class, similar to how I added it for object itself (in
object_methods[]). As I currently have it in 2.6, I can call __format__
on a new style class, but not a classic class:
$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
class newstyle(object): pass
...
class oldstyle: pass
...
newstyle().__format__('')
'__main__.newstyle object at 0x3d4d90'
oldstyle().__format__('')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: oldstyle instance has no attribute '__format__'
So my question is, to what do I need to add __format__ so that classic
classes will have a default implementation?
My knowledge of how classic classes are implemented is weak, so I don't
know where to add this.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
Guido van Rossum wrote:
On Feb 13, 2008 9:48 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?
I'm thinking that I need to add a __format__ to the most base old
style class, similar to how I added it for object itself (in
object_methods[]). As I currently have it in 2.6, I can call __format__
on a new style class, but not a classic class:
$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
class newstyle(object): pass
...
class oldstyle: pass
...
newstyle().__format__('')
'__main__.newstyle object at 0x3d4d90'
oldstyle().__format__('')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: oldstyle instance has no attribute '__format__'
So my question is, to what do I need to add __format__ so that classic
classes will have a default implementation?
My knowledge of how classic classes are implemented is weak, so I don't
know where to add this.
Ah, I see.
There is no root class of the classic class hierarchy (that's why
we're nixing it in 3.0 :-).
The customary pattern, used everywhere from len() to setattr(), is to
first check for an (instance) attribute with a special name
(__format__), and if that isn't found, to use a hard-coded fallback
implementation. For len() the fallback raises an exception; for
setattr() it puts the value in the instance __dict__.
Much to my surprise, this already works:
format(oldstyle(), '+^50s')
'+__main__.oldstyle instance at 0x3d91f8+'
So I guess it's a moot point. I'm using the same code as I use in 3.0,
where I call:
meth = _PyType_Lookup(Py_TYPE(value), format_str);
where format_str is __format__ interned. And I'm getting a value back
for old style classes.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
Guido van Rossum wrote: Much to my surprise, this already works: format(oldstyle(), '+^50s') '+__main__.oldstyle instance at 0x3d91f8+' So I guess it's a moot point. I'm using the same code as I use in 3.0, where I call: meth = _PyType_Lookup(Py_TYPE(value), format_str); where format_str is __format__ interned. And I'm getting a value back for old style classes. Eric. But now try overriding __format__(). The 3.0 code uses _PyType_Lookup() which is not traversing the class dicts for classic classes, so it won't find __format__ overrides. Okay, I see and understand that issue. But looking at len or getattr, I don't see how to generalize it to __format__. __len__ and __getattr__ have special support in the classes, with cl_getattr, tp_getattr, etc. I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? Thanks for your time. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
Nick Coghlan wrote: Eric Smith wrote: I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? I was going to suggest __enter__/__exit__, but that code relies mainly on existing opcodes and just does an attribute lookup rather than explicitly bypassing the instance dictionary. However, the source code for cPickle may provide some ideas (when it looks up _reduce__/__getstate__/etc). Those do look promising. Thanks! Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Eric Smith wrote:
I hate to be dense, but could you point me to some code that does
something similar but looks up the method by name?
I was going to suggest __enter__/__exit__, but that code relies mainly
on existing opcodes and just does an attribute lookup rather than
explicitly bypassing the instance dictionary.
However, the source code for cPickle may provide some ideas (when it
looks up _reduce__/__getstate__/etc).
Those do look promising. Thanks!
Or look in classobject.c itself; e.g. instance_str().
It uses a static helper function instance_getattr(), which while it
looks like what I want, I can't get to.
So I've come up with the following. I haven't checked for leaks yet,
but at least it appears to do what I want, for both classic and
new-style classes. I'm still porting over test cases from 3.0, so I'm
not convinced this is correct, yet.
/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
meth = _PyType_Lookup(Py_TYPE(value), str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
else {
PyErr_Format(PyExc_TypeError,
Type %.100s doesn't define __format__,
Py_TYPE(value)-tp_name);
goto done;
}
}
___
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] Adding __format__ to classic classes
[slight mailer problem, this might show up as a dupe. sorry]
Guido van Rossum wrote:
On Feb 13, 2008 2:57 PM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
However, the source code for cPickle may provide some ideas (when it
looks up _reduce__/__getstate__/etc).
Those do look promising. Thanks!
Or look in classobject.c itself; e.g. instance_str().
It uses a static helper function instance_getattr(), which while it
looks like what I want, I can't get to.
Well, it just implements PyObject_GetAttr for classic class instances...
So I've come up with the following. I haven't checked for leaks yet,
but at least it appears to do what I want, for both classic and
new-style classes. I'm still porting over test cases from 3.0, so I'm
not convinced this is correct, yet.
/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
You'd need PyErr_Clear() here the way this is written.
Okay.
But the
following call is redundant -- if that _PyType_Lookup() call finds
something, PyObject_GetAttr() will have found that too (or something
else).
meth = _PyType_Lookup(Py_TYPE(value), str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
else {
PyErr_Format(PyExc_TypeError,
Type %.100s doesn't define __format__,
Py_TYPE(value)-tp_name);
goto done;
}
}
Yes, but what's the or something else, and is it the right thing? Are
you saying I should call _PyType_Lookup first? But that's how I
started: if I do it that way, I can't override __format__ in a classic
class. As the code stands (PyObject_GetAttr then _PyType_Lookup), it's
definitely true that _PyType_Lookup will succeed when PyObject_GetAttr
will have failed.
Or should the logic be:
if is-new-style-class(Py_TYPE(value)):
lookup method with _PyType_Lookup(Py_TYPE(value))
else:
lookup method with PyObject_GetAttr(value)
And if so, how to test for is-new-style-class?
Sorry to be wasting your time, but I'm don't understand all of the
issues trying to support both new and classic classes in C. I think
I'll get the rest of PEP 3101 working, then come back to this issue.
It's pretty well contained. I'll spend some time understanding
classobject.c's implementation. It just seems like it shouldn't be this
hard to call a method (if it exists), given an instance.
I think my confusion leads to this problem (if in fact it's a problem):
format(object, '')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: __format__() takes exactly 1 argument (0 given)
format(object(), '')
'object object at 0x307408'
^D
Which works in the py3k branch.
Since PyObject_GetAttr() sets an AttributeError exception already, I
question the benefit of setting a different exception.
Agreed.
___
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] Adding __format__ to classic classes
Guido van Rossum wrote:
Try this:
if (PyInstance_Check(obj)) {
bound_method = PyObject_GetAttr(obj, str__format__);
if (!bound_method)
return NULL;
call it passing only the format string
Py_DECREF(bound_method);
return whatever the call returned
}
else {
do it the py3k way;
}
Yes! I had converged on something similar. Also, in the !bound_method
branch, I convert using str() or unicode() to get the same behavior as
object.__format__.
I have one more question, which I'll start in another thread.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
While implementing .format(), I need to call the builtin format() function, which I've already implemented (in bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded the same functionality into .format(), which seems like the wrong thing to do, given how complex the code is. I see 2 approaches: 1: exposing builtin_format(), probably giving it another name (PyObject_Format?) and moving it somewhere other than bltinmodule.c. 2: Instead of calling the C code directly, lookup format in Python's builtins, and call it. This, I think, would allow you to override the global format() function if you wanted to modify the behavior (although I can't think of any use case for wanting to do that). I don't see where either behavior is specified in the PEP. If option 2 is preferred, could someone give me a pointer to how to find a builtin function from C code? Thanks. ___ 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] Calling a builtin from C code; PEP 3101 format() builtin
Greg Ewing wrote: Eric Smith wrote: 1: exposing builtin_format(), probably giving it another name (PyObject_Format?) and moving it somewhere other than bltinmodule.c. PyObject_Format sounds more like an API for invoking the __format__ lookup mechanism. Maybe something like PyObject_DefaultFormat would be better. I see it like: PyObject_Str(o) gives you str(o), PyObject_Unicode(o) gives you unicode(o) so PyObject_Format(o, spec) give you format(o, spec). All 3 of them do things with __special__ methods. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Greg Ewing wrote: Eric Smith wrote: 1: exposing builtin_format(), probably giving it another name (PyObject_Format?) and moving it somewhere other than bltinmodule.c. PyObject_Format sounds more like an API for invoking the __format__ lookup mechanism. Maybe something like PyObject_DefaultFormat would be better. I see it like: PyObject_Str(o) gives you str(o), PyObject_Unicode(o) gives you unicode(o) so PyObject_Format(o, spec) give you format(o, spec). All 3 of them do things with __special__ methods. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Eric Smith wrote: Greg Ewing wrote: Eric Smith wrote: 1: exposing builtin_format(), probably giving it another name (PyObject_Format?) and moving it somewhere other than bltinmodule.c. PyObject_Format sounds more like an API for invoking the __format__ lookup mechanism. Maybe something like PyObject_DefaultFormat would be better. I see it like: PyObject_Str(o) gives you str(o), PyObject_Unicode(o) gives you unicode(o) so PyObject_Format(o, spec) give you format(o, spec). All 3 of them do things with __special__ methods. Having heard no objections, I'm going to call this PyObject_Format and put it in abstract.c. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
Eric Smith wrote:
Guido van Rossum wrote:
For data types whose output uses only ASCII, would it be acceptable if
they always returned an 8-bit string and left it up to the caller to
convert it to Unicode? This would apply to all numeric types. (The
date/time types have a strftime() style API which means the user must
be able to specifiy Unicode.)
I'm finally getting around to finishing this up. The approach I've
taken for int, long, and float, is that they take either unicode or str
format specifiers, and always return str results. The builtin format()
deals with converting str to unicode, if the format specifier was
originally unicode. This all works great. It allows me to easily
implement both ''.format and u''.format taking int, long, and float
parameters.
I'm now working on datetime. The __format__ method is really just a
wrapper around strftime. I was assuming (or rather hoping) that
strftime does the right thing with unicode and str (unicode in = unicode
out, str in = str out). But it turns out strftime doesn't accept unicode:
$ ./python
Python 2.6a0 (trunk:60845M, Feb 15 2008, 21:09:57)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type help, copyright, credits or license for more information.
import datetime
datetime.date.today().strftime('%y')
'08'
datetime.date.today().strftime(u'%y')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: strftime() argument 1 must be str, not unicode
As part of this task, I'm really not up to the job of changing strftime
to support both str and unicode inputs. So I think I'll put all of the
__format__ code in place to support it if and when strftime supports
unicode. In the meantime, it won't be possible for u''.format to work
with datetime objects.
'year: {0:%y}'.format(datetime.date.today())
'year: 08'
u'year: {0:%y}'.format(datetime.date.today())
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: strftime() argument 1 must be str, not unicode
The bad error message is a result of __format__ passing on unicode to
strftime.
There are, of course, various ugly ways to work around this involving
nested format calls.
Maybe I'll extend strftime to unicode for the PyCon sprint.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
André Malo wrote: I guess, a clean and complete solution (besides re-implementing the whole thing) would be to resolve each single format character with strftime, decode according to the locale and re-assemble the result string piece by piece. Doh! That's along the lines of what I was thinking. strftime already does some of this to support %[zZ]. But now that I look at time.strftime in py3k, it's converting the entire unicode string to a char string with PyUnicode_AsString, then converting back with PyUnicode_Decode. ___ 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] Different float formatting on Windows and Linux
The tests for float.__format__ are breaking on Windows, because of this issue: http://bugs.python.org/issue1600. Basically, Windows is using 3 digits for exponents 100, and Linux (and at least MacOS) are using 2. The patch attached to the issue proposes changing all platforms to use at least 3 digits. It affects both '%' formatting and __format__ formatting. Altering all float formatting involving exponents is a pretty big change to make, and I want to get opinions here before making this change. Guido's comments in the issue are supportive, and I agree that the consistency would be good. I'm just concerned about changing the output for existing code. I suppose another option would be to modify Windows to use 2 digits for exponents 100. I guess it just depends on whose output you want to break! I think the options are: 1: Do nothing. Adapt the tests to deal with the differences. 2: Force 3 characters for exponents 100. 3: Force 2 characters for exponents 100. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
André Malo wrote: * Eric Smith wrote: But now that I look at time.strftime in py3k, it's converting the entire unicode string to a char string with PyUnicode_AsString, then converting back with PyUnicode_Decode. Looks wrong to me, too... :-) nd I don't understand Unicode encoding/decoding well enough to describe this bug, but I admit it looks suspicious. Could someone who does understand it open a bug against 3.0 (hopefully with an example that fails)? The bug should also mention that 2.6 avoids this problem entirely by not supporting unicode with strftime or datetime.__format__, but 2.6 could probably leverage whatever solution is developed for 3.0. Thanks. ___ 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] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: [Eric Smith] Speaking for myself, these features are generally useful, and are so even without the new integer literal syntax. I'm curious how these are useful to you in Py2.6 where they are not invertible. In Py3.0, we can count on x == int(bin(x), 2) x == eval(bin(x)) I don't see how these could work in Py2.6 without changing the parser and changing the int() function. Why would you ever want to create a string like '0o144' when there is no way to convert the string back into a value? Because I need to output the values, for debugging and other purposes. I have no need to eval something I've bin'd, so I don't need them to be invertible. Same with hex. I realize I could just write these functions myself in Python, and not use the builtins. But I don't see the drawback of them being in 2.6. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: [Eric Smith] I'm going to work on backporting PEP 3127, specifically the hex, oct(), and bin() builtins. IMO, these should not be backported. They are strongly associated with 3.0's new literal syntax. They don't don't really fit in with 2.6 and don't make 2.6 any more attractive. I'm just going by what's on the spreadsheet. I assumed that these were all vetted. http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGggid=2 Speaking for myself, these features are generally useful, and are so even without the new integer literal syntax. Their existence would make 2.6 more attractive to me. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3127 to trunk
Robert Brewer wrote: Raymond Hettinger wrote: I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced. Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions. Unless you're trying to write code to work with both 2.6 and 3.0. ___ 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] Backporting PEP 3127 to trunk
Guido van Rossum wrote: I wonder if, in order to change the behavior of various built-in functions, it wouldn't be easier to be able to write from future_builtins import oct, hex # and who knows what else This makes sense to me, especially if we have a 2to3 fixer which removes this line. I'll work on implementing future_builtins. ___ 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] Backporting PEP 3127 to trunk
Robert Brewer wrote: Eric Smith wrote: Robert Brewer wrote: Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions. Unless you're trying to write code to work with both 2.6 and 3.0. Who would try that when PEP 3000 says (in bold type no less): There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. ? Yes, but it also describes the recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously. That is to run 2to3 on 2.6 code (which is -3 clean), and not edit the resulting code. I'm trying to enable that for code which wants to use some (small) 3.0 features. I don't see the harm in that. I think this means that the existing oct and hex builtins should raise a -3 warning. The future_builtins version would not raise a warning. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
Georg Brandl wrote: Eric Smith schrieb: Guido van Rossum wrote: I wonder if, in order to change the behavior of various built-in functions, it wouldn't be easier to be able to write from future_builtins import oct, hex # and who knows what else This makes sense to me, especially if we have a 2to3 fixer which removes this line. I'll work on implementing future_builtins. Will the future map and filter also belong there (and if they are imported from future_builtins, 2to3 won't put a list() around them)? I can certainly do the mechanics of adding the new versions of map and filter to future_builtins, if it's seen as desirable. Maybe we could have 2to3 not put list() around map and filter, if there's been an import of future_builtins. I realize that there are pathological cases where 2to3 doesn't know that a usage of map or filter would really be the generator version from future_builtins, as opposed to the actual list-producing builtins. But would it be good enough to take an import of future_builtins as a hint that the author was aware that 2to3 wasn't going to change map and filter? Still an open issue in my mind is adding a -3 warning to oct and hex, and now conceivably map and filter. Would that be going too far? Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future_builtins
Guido van Rossum wrote: I don't think a -3 warning for oct or hex would do any good. I'm curious as to why. oct and hex have different behavior in 3.0, which is what I thought -3 was for. hex might be overkill, as the only differences are the L and the __hex__ behavior. But oct is always different. ___ 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-3000] Code freeze?
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote: Hey Barry! Hi Christian! When are you planing to freeze the code of the trunk and branches/py3k for the upcoming alpha releases? I'll merge the last modifications from 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good, except for the two profile tests on 3.0. I'm going to test Windows later. Okay, let's go ahead and make it official. I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to that: 2200 UTC Friday 29-Feb-2008. Argh! I was going to check the last of the PEP 3127 changes in tonight, but I won't make it by 6 pm EST. I have them finished, but no tests written, so I'm not comfortable checking them in yet. I guess it's no big deal that they slip until the next alpha. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
Barry Warsaw wrote: Okay, let's go ahead and make it official. I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to that: 2200 UTC Friday 29-Feb-2008. Argh! I was going to check the last of the PEP 3127 changes in tonight, but I won't make it by 6 pm EST. I have them finished, but no tests written, so I'm not comfortable checking them in yet. I guess it's no big deal that they slip until the next alpha. Sorry, I notice my message might not have been clear. As of this writing, you have 23 hours and 54 minute before code freeze :). Code freeze: 2200 UTC 29-Feb-2008 Alpha making: 2300 UTC 29-Feb-2008 Your message was clear, it's my reading comprehension that is low. Now you've removed my excuse for not getting this done. To the keyboard! Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Code freeze?
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 4:03 PM, Eric Smith wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote: Hey Barry! Hi Christian! When are you planing to freeze the code of the trunk and branches/py3k for the upcoming alpha releases? I'll merge the last modifications from 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good, except for the two profile tests on 3.0. I'm going to test Windows later. Okay, let's go ahead and make it official. I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to that: 2200 UTC Friday 29-Feb-2008. Argh! I was going to check the last of the PEP 3127 changes in tonight, but I won't make it by 6 pm EST. I have them finished, but no tests written, so I'm not comfortable checking them in yet. I guess it's no big deal that they slip until the next alpha. Sorry, I notice my message might not have been clear. As of this writing, you have 23 hours and 54 minute before code freeze :). Code freeze: 2200 UTC 29-Feb-2008 Alpha making: 2300 UTC 29-Feb-2008 It turns out I'm not going to make this first alpha with the rest of the PEP 3127 changes. The code doesn't handle all combinations of (int, long) and (str, unicode). I'll get it finished before the next alpha. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] range in future_builtins?
In the keynote, Guido mentioned switching from range to xrange in 2.6 code, as a migration strategy. Another option would be to add range to future_builtins, and have it call xrange. Would that be desirable? ___ 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] socket.create_connection slow
Kristján Valur Jónsson wrote: Aha, thanks, since my wireshark wasn't working. I boiled a few pints of water (thanks, Google) and came up with this: http://support.microsoft.com/kb/175523 Here is the summary: Note that with other implementations of TCP, such as those commonly found in many UNIX systems, the connect() fails immediately upon the receipt of the first ACK/RST packet, resulting in the awareness of an error very quickly. However, this behavior is not specified in the RFCs and is left to each implementation to decide. The approach of Microsoft platforms is that the system administrator has the freedom to adjust TCP performance-related settings to their own tastes, namely the maximum retry that defaults to 3. The advantage of this is that the service you're trying to reach may have temporarily shut down and might resurface in between SYN attempts. In this case, it's convenient that the connect() waited long enough to obtain a connection since the service really was there. Yet another undefined thing affecting us, Martin. I know it's pointless to express my shock here, but I can't resist. It's truly amazing to me that they'd delay the connect call's failure for a second by default, in hopes that the other end might come back up between SYN's. How often could that possibly happen? Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions
Terry Reedy wrote: Cameron Simpson wrote: Back at uni we had to implement a small language in our compilers class and the lecturer had specified a proper generic while loop, thus: loop: suite while invariant suite endloop In Python, that is spelled while True: suite if not invariant: break suite Indeed. This is the well known loop and a half problem. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ac_sys_system == Monterey*?
s...@pobox.com wrote: From configure.in: # The current (beta) Monterey compiler dies with optimizations # XXX what is Monterey? Does it still die w/ -O? Can we get rid of this? case $ac_sys_system in Monterey*) OPT= ;; esac What is Monterey? Can this check be removed from trunk/py3k branches? This post http://mail.python.org/pipermail/patches/2000-August/001708.html would have you believe it's a 64-bit AIX compiler. ___ 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] pprint(iterator)
Terry Reedy wrote: Ron Adam wrote: Steven D'Aprano wrote: Michael Foord wrote: Don't we have a pretty-print API - and isn't it spelled __str__ ? Not really. If it were as simple as calling str(obj), there would be no need for the pprint module. I agree. And when I want to use pprint, there are usually additional output formatting requirements I need that isn't a one size fits all type of problem. I don't see how you can have a standard interface (like __pprint__), and have additional, per-object formatting parameters. But that's beside the point, I don't like __pprint__ in any event. Too special. Like others, I am wary of over-expanding the list of special methods. Perhap format strings could have a fourth conversion specifier, !p (pretty) in addition to !s, !r, and !a. What would format() do with !p? With !s, it calls str(o), with !r, it calls repr(o). !p could call o.__pprint__(), but that's the special method you're trying to avoid! (I don't recall if I added !a, and a machine that would know isn't available to me just now.) Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4285 Review
Aahz wrote: On Tue, Feb 03, 2009, Ross Light wrote: Hello, python-dev. I submitted a patch a couple weeks ago for Issue 4285, and it has been reviewed and revised. Would someone please review/commit it? Thank you. http://bugs.python.org/issue4285 When sending in a request like this, it's useful to summarize the issue; few people know bug reports by number, and at least some people who might be interested in looking probably won't bother if they have no clue whether it's in their area of expertise. I'll review it with the intention of committing it. The subject is Use a named tuple for sys.version_info. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The interpreter accepts f(**{'5':'foo'}); is this intentional?
Calvin Spealman wrote:
I would favor this not being constrained. I don't want every use of **
to cause a pattern match to verify each key. I would even be fine
without the check for being strings. Define what it should be, but let
the implementation be lax. It is no different from any other place
where you need to know its not a promise, just an artifact, and
shouldn't rely on what the implementation currently does or does not
force.
I agree. There was a similar issue in http://bugs.python.org/issue2598,
and we decided not to do anything about it.
Eric.
On Thu, Feb 5, 2009 at 3:03 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
I can't find documentation about whether there are constraints imposed
on the keys in the map passed to a function via **, as in f(**d).
According to
http://docs.python.org/reference/expressions.html#id9
, d must be a mapping.
test_extcall.py implies that the keys of this map must be strings in the
following test:
f(**{1:2})
Traceback (most recent call last):
...
TypeError: f() keywords must be strings
But must the keys be valid python identifiers?
In particular, the following is allows by the Python 2.5.2 and the
Jython 2.2.1 interpreters:
f(**{'1':2})
{'1': 2}
Is this behavior required somewhere by the Python language spec, or is
it an error that just doesn't happen to be checked, or is it
intentionally undefined whether this is allowed?
Michael
___
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/ironfroggy%40gmail.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] Issue 4285 Review
Eric Smith wrote: Aahz wrote: On Tue, Feb 03, 2009, Ross Light wrote: Hello, python-dev. I submitted a patch a couple weeks ago for Issue 4285, and it has been reviewed and revised. Would someone please review/commit it? Thank you. http://bugs.python.org/issue4285 When sending in a request like this, it's useful to summarize the issue; few people know bug reports by number, and at least some people who might be interested in looking probably won't bother if they have no clue whether it's in their area of expertise. I'll review it with the intention of committing it. The subject is Use a named tuple for sys.version_info. Committed in r69331 (trunk) and r69346 (py3k). I hope I got the merge/block command correct. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] regrtest hangs on test_tk_guionly
In the trunk, test_tk_guionly hangs if I run it through regrtest. This is on a Fedora Core 6 box, without X installed. If I run test_tk_guionly directly, it exits saying there's no DISPLAY set, which is what I'd expect: --8-- [trunk]$ ./python Lib/test/test_ttk_guionly.py Traceback (most recent call last): File Lib/test/test_ttk_guionly.py, line 11, in module raise test_support.TestSkipped(ttk not available: %s % msg) test.test_support.TestSkipped: ttk not available: no display name and no $DISPLAY environment variable [29788 refs] --8-- If I run regrtest with (or without) -v, it hangs without any output from test_tk_guionly: --8-- ... OK test_transformer Test multiple targets on the left hand side. ... ok -- Ran 1 test in 0.020s OK test_ttk_guionly hangs here --8-- I'm not seeing a problem in the py3k branch. There, test_tk_guionly is skipped: --8-- test_ttk_guionly test_ttk_guionly skipped -- ttk not available: no display name and no $DISPLAY environment variable --8-- I'm not sure how to further isolate this, since I can't duplicate it when running the test by itself. I'm mostly curious if anyone else is seeing this problem. If it's just me, I'll just switch to a Mac, where the problem doesn't occur (if for no other reason, because ttk is not available). If others are seeing a problem, I'll spend some time isolating it. Is anyone else seeing this problem? Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] regrtest hangs on test_tk_guionly
Guilherme Polo wrote: On Fri, Feb 6, 2009 at 1:14 PM, Eric Smith e...@trueblade.com wrote: In the trunk, test_tk_guionly test_ttk_guionly, right ? Right, sorry. hangs if I run it through regrtest. This is on a Fedora Core 6 box, without X installed. Does it hang if you run it alone through regrtest, or, together with all the other tests ? It does not hang: [trunk]$ ./python Lib/test/regrtest.py test_ttk_guionly test_ttk_guionly test_ttk_guionly skipped -- ttk not available: no display name and no $DISPLAY environment variable 1 test skipped: test_ttk_guionly 1 skip unexpected on linux2: test_ttk_guionly I've noticed it, it is on http://bugs.python.org/issue5122 The second part of the issue description is actually unrelated to the problem (or at least I'm almost sure it is), so you may discard it. I wasn't able to duplicate it here, but I could try installing fedora here to try reproducing and see if I can solve it. Unfortunately I can't give you access to this machine. Maybe http://www.snakebite.org/ will be able to help. If you think my issue is related to 5122, I'll reply to that issue and move the discussion there. I can test on a Fedora 10 box, too. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
We need a really long lead time before we can remove these. I recommend starting with a *silent* deprecation in 3.1 combined with a PR offensive for the new names. I think the old names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? ___ 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] Ext4 data loss
Antoine Pitrou wrote: I think your synced flag is too vague. Some applications may need the file to be synced on close(), but some others may need it to be synced at regular intervals, or after each write(), etc. Why wouldn't sync just be an optional argument to close(), at least for the sync_on_close case? Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ext4 data loss
Antoine Pitrou wrote: Eric Smith eric at trueblade.com writes: Why wouldn't sync just be an optional argument to close(), at least for the sync_on_close case? It wouldn't work with the with statement. Well, that is a good reason, then! ___ 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] Can I modify string.Formatter._vformat?
I'm implementing support for auto-numbering of str.format() fields (see http://bugs.python.org/issue5237). I'm reasonably sure that when I'm done modifying the C implementation I'll need to change the signatures of string.Formatter._vformat, str._formatter_parser, and/or str._formatter_field_name_split. (They need to support the state needed to track the auto-number field counter.) I've always considered these internal implementation details of str.format and string.Formatter. They begin with underscores and are not documented. Is there any problem with modifying these in 2.7 and 3.1? I assume not, but I want to make sure it doesn't give anyone heartburn. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)
Raymond Hettinger wrote: Eric Smith pointed-out that these are already handled by the n specifier in the locale module (albiet only for integers). It's supported by float, but it's just not very useful. For Decimal it's unsupported. Maybe this isn't a distinction worth pointing out. Proposal I (from Nick Coghlan) == ... [[fill]align][sign][#][0][width][,][.precision][type] Proposal II (to meet Antoine Pitrou's request) == ... [[fill]align][sign][#][0][width][T[tsep]][dsep precision][type] I was going to suggest that since the locale name for this is grouping, we use G. But since we're not doing a general-purpose grouping implementation, I think T better says we're doing thousands, not general grouping. Perhaps this should go in a rationale section if we opt for T. Now that I think about it, G is already a valid type, so it wouldn't work, anyway. format(1234, 8T,d)-- ' 1,234' For proposal 2, this case is unfortunate. Because for integers, there is no decimal allowed in the mini-language (it's currently illegal to use 8.1d), you'd only ever add the thousands, but you'd always need the T. It would be nice to come up with a specification that would degrade for integers such that 8,d would give ' 1,234'. Proposal 1 is much nicer in that regard, although I definitely like the fact that the actual characters used for DOT and COMMA can be specified with proposal 2. Maybe you'd never really use T,, since the comma is redundant, and you'd say: format(1234, 8Td)-- ' 1,234' in normal use. But d is also the default, so it just becomes: format(1234, 8T) -- ' 1,234' I like approach 2 in general. I'll give some thought to other, similar schemes which would allow 8, or 8,d to work. I think people will write 8, and expect1,234, not an error. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
P.J. Eby wrote: As someone else suggested, moving some of the functionality to PEP 302 interfaces would also help. Most of the code, though, deals with locating/inspecting installed distributions, resolving version requirements, and managing sys.path. And most of the nastiest complexity comes from trying to support true filename access to resources -- if that were dropped from the stdlib, there'd be no need for egg caches and the like, along with all the complexity entailed. Application environments such as Chandler, Trac, Zope, etc. that want their plugins to live in .egg files wouldn't necessarily be able to use such an API, but the independent pkg_resources wouldn't be disappearing. (Of course, they could also implement application-specific file extraction, if the stdlib API included the ability to inspect and open zipped resources.) Could you comment on why they couldn't use such an API? ___ 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] version compare function into main lib
anatoly techtonik wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? snip What do you think about adding cmpversions(first, second, strict=false) based on distutils into main lib? distutils _is_ already in the main lib, that is, the standard library. Will it be more appropriate to isolate the function into versions module? Should it be rewritten to remove re dependency in this case? Given that re is also in the standard library, and this is hardly speed critical, I'd say no. Distutils version comparisons: http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/version.py?view=markup I don't see the point of moving this, unless it's part of some larger, radical fix distutils effort. And even then I'm not convinced. This probably belongs on the python-ideas mailing list, or on the distutils SIG list. I expect you'll see a lot of discussion on distutils SIG list in the coming days. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
M.-A. Lemburg wrote: On 2009-03-27 04:19, Guido van Rossum wrote: - keep distutils, but start deprecating certain higher-level functionality in it (e.g. bdist_rpm) - don't try to provide higher-level functionality in the stdlib, but instead let third party tools built on top of these core APIs compete Should this be read as: - remove bdist_rpm from the stdlib and let it live on PyPI ? As one of the people who proposed this, I think it means: move bdist_rpm, bdist_msi, etc. out of distutils, but provide some of them with the standard Python installation. I'm certain that as part of the refactoring and simplification of distutils we'll gradually move the existing bdist_* commands into separate, stand-alone things (scripts, callable modules, or something). We'll need to do this if only for testing, so we may as well make them work. Instead of removing such functionality, I think we should add more support for standard packaging formats to distutils, e.g. bdist_deb, bdist_pkg, etc. Agreed. And for eggs, there should be a standard bdist_egg, written against the core distutils APIs (*), creating archives which other Python package managers can then use in whatever way they seem fit. Agreed. Just please don't tie eggs to one specific package manager, e.g. having to install setuptools just to run eggified packages is just plain wrong. The format itself doesn't require this and neither should the software shipped with those eggs. I think that whatever we produce will need to be supported by the standalone version of the installer portion that will be backported and separately available. ___ 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] setuptools has divided the Python community
Olemis Lang wrote: On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote: 2009/3/27 Guido van Rossum gu...@python.org: - keep distutils, but start deprecating certain higher-level functionality in it (e.g. bdist_rpm) - don't try to provide higher-level functionality in the stdlib, but instead let third party tools built on top of these core APIs compete Please don't move bdist_wininst out of the core, though! I'd argue that Windows is a special case, as many Windows users don't have the ability to build their own extensions, H ... what about devs (me?) trying to build installers for multiple platforms being in a single OS (let's say Ubuntu ...) ? IMO in this case where policies are unique for a particular OS-flavour (deb, rpms, and so on ...) ... there should be a single way to package your app and to conform to the standards agreed by distros (e.g. Debian) and maintainers ... isnt it enough std to be in stdlib ? I'd really like to have those (... at least the most influential systems ... rpm, debs, and maybe two or three more that I'm missing here ...) The idea is to make the metadata extensible, so that for example Debian specific information can be put in the same config file that contains the normal metadata. I guess it would even be possible for this additional metadata to be in a separate config file. That way if someone downstream from me says I can automatically build a .deb file if you'd just include this metadata, I could easily do that. I don't think it's reasonable that a package builder could possibly know all of the config information. To some extent, this is all currently possible with setup.cfg, and I do that myself. I'm also not convinced there will be a single bdist_rpm (or whatever) replacement. It's entirely possible that different people would want to build different flavors of rpm's from the same metadata. Someone might be a real FHS devotee, and someone else might have practical reasons to not follow it. Indeed I'd like to know the arguments behind «deprecating certain higher-level functionality in it (e.g. bdist_rpm)» BTW ... perhaps they'r self-explanatory and therefore I should not be asking this at all ... :P I believe it's largely a refactoring. It's just too complicated and difficult to extend the way it is now. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version compare function into main lib
Martin v. Löwis wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. Yes. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it 10.3.40-beta, but perhaps 10.3.40b1 or 10.3.40~beta. I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
M.-A. Lemburg wrote: On 2009-03-27 17:07, P.J. Eby wrote: At 11:37 PM 3/26/2009 -0500, Eric Smith wrote: P.J. Eby wrote: As someone else suggested, moving some of the functionality to PEP 302 interfaces would also help. Most of the code, though, deals with locating/inspecting installed distributions, resolving version requirements, and managing sys.path. And most of the nastiest complexity comes from trying to support true filename access to resources -- if that were dropped from the stdlib, there'd be no need for egg caches and the like, along with all the complexity entailed. Application environments such as Chandler, Trac, Zope, etc. that want their plugins to live in .egg files wouldn't necessarily be able to use such an API, but the independent pkg_resources wouldn't be disappearing. (Of course, they could also implement application-specific file extraction, if the stdlib API included the ability to inspect and open zipped resources.) Could you comment on why they couldn't use such an API? If a plugin includes C code (.so/.dll), or uses a library that operates on filenames rather than bytes in memory (e.g. gettext), then the resources would need to be extracted from the .egg. pkg_resources transparently extracts such resources to a cache directory when you ask for a resource's filename, rather than asking for a stream or string of its contents. This feature represents a significant chunk of the complexity and code size of pkg_resources -- and I was proposing ways to cut down on that complexity and code size, for a (limited) stdlib version of the functionality. This functionality is one of the more annoying setuptools features. It causes each and every user of e.g. Trac to have their own little version of the same piece of software in their home dir cache. The solution to this is simple: don't use ZIP files for installed packages, instead unzip them into normal directories on sys.path. This makes all these problems go away and allows users to access embedded documentation, configuration, etc. Zip files are great for shipping packages to the end-user, but there's no need to keep them zipped once they get there. I also think the feature should go. If you want functionality that's so difficult to provide when you install as a zip file, the answer is not to make things more complex, but to not install as zip files. ___ 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] setuptools has divided the Python community
Olemis Lang wrote: I also think the feature should go. If you want functionality that's so difficult to provide when you install as a zip file, the answer is not to make things more complex, but to not install as zip files. What about environments like Google App Engine ? I mean, AFAIK using ZIP files is the *official* solution to meet some quotas requirements ... CMIIW anyway ... I mean, for example: what if someone writes an app containing resources like message catalogs for i18n, uploads it to GAE using ZIP files and still wants to use the MO files (i.e. resources) for translation (i.e. for anything else ...) ... H ? I mentioned yesterday (in the language summit) that we really need to get all the requirements together before we start any work. I fear that there are many hidden requirements (or ones that I'm personally not aware of, at least). I don't know gettext well enough give an answer yet. ___ 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] version compare function into main lib
Martin v. Löwis wrote: I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Procedurally, I think it's a very bad approach. I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils). Agreed. Specifications first, for all of this work. ___ 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] splitting out bdist_*
Martin v. Löwis wrote: I do think that it's relevant that the respective operating system packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not very useful to have a bdist_deb that nobody actually builds debs with. I think that conclusion is invalid: just because the distributions don't use it doesn't mean that nobody uses it. As a data point, there are 16 packages on PyPI that release RPMs (I haven't checked how they actually built them, though). And I personally use bdist_rpm for my work, which I distribute to a farm of servers under my control. So no doubt it's used. In fact, .deb is a proof that it does *not* help to have the package commands outside distutils. For .deb, the command actually *is* outside distutils (there is no bdist_deb in distutils) - and it hasn't helped. It proves that it doesn't help given the current state of affairs. I suspect that if all of this additional information needed to build a .deb (for example) could be included as metadata in the python package (using the word package loosely), that it would be. It would make the ultimate packager's life easier, and it's no real burden for the original author. ___ 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] Version strings
Martin v. Löwis wrote: I just collected the version strings of versions that got released to PyPI, and put up the list on http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions That's excellent, thank you. The following chunk of text is present. I don't really care, except that it might mean a bug in your extraction routine. Or maybe it's just a very wacky version string! Sysv_ipc gives Python programs access to System V semaphores, shared memory and message queues. Most (all?) Unixes (including OS X) support System V IPC. Windows+Cygwin 1.7 might also work. Sample code is included. This extension is released under the GPL. You might also be interested in the similar POSIX IPC module at: http://semanchuk.com/philip/posix_ipc/ T-0.3.4 (BitTornado) Trunk ___ 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] splitting out bdist_*
Stephen J. Turnbull wrote: Eric Smith writes: And I personally use bdist_rpm for my work, which I distribute to a farm of servers under my control. So no doubt it's used. Sure, but use for internal distribution is very different from to problem its being asked to solve now, isn't it? IIUC, you're basically using RPM as an installer for a standalone application, where you set policy at both ends, packaging and installation. This may be a group of modules which may have internal interdependencies, but very likely the environment doesn't change much. Pretty much anything will do in that kind of situation, and I don't think it would matter to you if there are zero, one, or twelve such tools in stdlib, as long as there's one you like in PyPI somewhere. I was just pointing out that bdist_rpm has users, and it's not likely to be abandoned. It's certainly true that different users have different use cases for it. It's this lack of understanding of all the use cases that most concerns me about this overall effort. How can we know if we succeeded if we don't all agree on the state we're trying to get to? To be concrete, I think distutils should support (among other things): - entry points for plugins - entry points as used for producing console and windowed scripts - dependency declarations for other python packages - dependency declarations for non-python packages But maybe these goals aren't shared by others, and don't fall into anyone else's make distutils better concept. PJE pointed out A library that targets Python 2.4 and 2.5 and uses wsgiref, sqlite, ctypes, or ElementTree, for example, may have different dependencies depending on the version it is being installed in. Is that something we want to support? [That .deb tools are necessarily maintained outside of bdist] proves that [external maintenance] doesn't help given the current state of affairs. I suspect that if all of this additional information needed to build a .deb (for example) could be included as metadata in the python package (using the word package loosely), that it would be. It would make the ultimate packager's life easier, and it's no real burden for the original author. I'm not sure what you mean by it would be. Are you referring to what I believe to be true, that because Python and Python-based apps need to integrate with the rest of the OS, it's quite burdensome for module authors to include the necessary information, which is likely to vary from packaging tool to packaging tool, and according to policy even among packagers using the same tool? Or do you mean that it would be useful, so it would be nice if such information were included, and that as you see it the required effort would be small? I don't see how they differ. It's definitely true that packagers using the same tool might want to produce different package layouts and no doubt other differences. I don't see why it wouldn't be easy to have these differences driven by different policies acting on the same metadata, or small amounts of custom (per-packager) metadata. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython and C++ object GC
Nick Coghlan wrote: Csaba Balazs wrote: Hello Everybody, I would like to use a C++ gui library with the following (simplified) interface in Python. This is a question for python-list/comp.lang.python (i.e. development *using* Python, including the C API), not python-dev (which is for development of the language itself). There's also the capi-sig mailing list, http://mail.python.org/mailman/listinfo/capi-sig. ___ 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] Test failures under Windows?
Kristján Valur Jónsson wrote: Btw, I am working on finding out the test suite failures for test_multiprocessing. Some of those are caused by force builds on a branch, so make sure the errors are still occurring before you put too much effort into this. We made the branch before some recent fixes to the py3k branch. But of course there may still be errors that exist. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote: On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. -1 to adding it to the 2.x series. There was much discussion around adding features to 2.x *and* 3.0, and the consensus seemed to *not* add new features to 2.x and use those new features as carrots to help lead people into 3.0. Actually, isn't the policy just that nothing can go into 2.7 that isn't backported from 3.1? Whether the actual backport happens or not is up to the developer though. OTOH, we talked about a lot of things and my recollection is probably fuzzy. I believe Barry is correct. The official policy is no features in 2.7 that aren't also in 3.1. I personally think I'm not going to put anything else in 2.7, specifically the ',' formatter stuff from PEP 378. 3.1 has diverged too far from 2.7 in this regard to make the backport easy to do. But this decision is left up to the individual committer. ___ 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] Shorter float repr in Python 3.1?
Mark Dickinson wrote:
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get this into Python 3.1.
Any thoughts/objections/counter-proposals/...?
As part of the decision process, we've tried this on several buildbots,
and it has been successful on at least:
AMD64 Gentoo:
http://www.python.org/dev/buildbot/3.x/amd64%20gentoo%203.x/builds/592
PPC Debian unstable:
http://www.python.org/dev/buildbot/3.x/ppc%20Debian%20unstable%203.x/builds/584
Sparc Solaris 10:
http://www.python.org/dev/buildbot/3.x/sparc%20solaris10%20gcc%203.x/builds/493
The Sparc test failed, but that wasn't our fault! Our tests succeeded.
These builds are in addition to x86 Linux and x86 Mac, which we've
developed on.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecating PyOS_ascii_formatd
Assuming that Mark's and my changes in the py3k-short-float-repr branch get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its functionality is largely being replaced by PyOS_double_to_string, which we're introducing on our branch. PyOS_ascii_formatd was introduced to fix the issue in PEP 331. PyOS_double_to_string addresses all of the same issues, namely a non-locale aware double-to-string conversion. PyOS_ascii_formatd has an unfortunate interface. It accepts a printf-like format string for a single double parameter. It must parse the format string into the parameters it uses. All uses of it inside Python already know the parameters and must build up a format string using sprintf, only to turn around and have PyOS_ascii_formatd reparse it. In the branch I've replaced all of the internal calls to PyOS_ascii_format with PyOS_double_to_string. My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in 3.2. The 2.7 situation is tricker, because we're not planning on backporting the short-float-repr work back to 2.7. In 2.7 I guess we'll leave PyOS_ascii_formatd around, unfortunately. FWIW, I didn't find any external callers of it using Google code search. And as a reminder, the py3k-short-float-repr changes are on Rietveld at http://codereview.appspot.com/33084/show. So far, no comments. ___ 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] Deprecating PyOS_ascii_formatd
Nick Coghlan wrote: Eric Smith wrote: And as a reminder, the py3k-short-float-repr changes are on Rietveld at http://codereview.appspot.com/33084/show. So far, no comments. Looks like you were able to delete some fairly respectable chunks of redundant code! Wait until you see how much nasty code gets deleted when I can actually remove PyOS_ascii_formatd! And thanks for your comments on Rietveld, especially catching the memory leak. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark has uploaded our newest work to Rietveld, again at
http://codereview.appspot.com/33084/show. Since the last version, Mark
has added 387 support (and other fixes) and I've added localized
formatting ('n') back in as well as ',' formatting for float and int. I
think this addresses all open issues. If you have time, please review
the code on Rietveld.
We believe we're ready to merge this back into the py3k branch. Pending
any comments here or on Rietveld, we'll do the merge in the next day or so.
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be great:
Windows (preferably 64-bit)
Itanium
Old Intel/Linux (e.g., the snakebite nitrogen box)
Something bigendian, like a G4 Mac
We're pretty well tested on x86 Mac and Linux, and I've run it once on
my Windows 32-bit machine.
I have a Snakebite account, and I'll try running on nitrogen once I
figure out how to log in again.
I just had Itanium and PPC buildbots test our branch, and they both
succeeded (or at least failed with errors not related to our changes).
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Benjamin Peterson wrote: Cool. Will you use svnmerge.py to integrate the branch? After having some odd behavior merging the io-c branch, suggest you just apply a patch to the py3k branch, We're just going to apply 2 patches, without using svnmerge. First we'll add new files and the configure changes. Once we're sure that builds everywhere, then the second step will actually hook in the new functions and will have the formatting changes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: In article 49e3d34e.8040...@trueblade.com, Eric Smith e...@trueblade.com wrote: Before then, if anyone could build and test the py3k-short-float-repr branch on any of the following machines, that would be great: [...] Something bigendian, like a G4 Mac I'll crank up some OS X installer builds and run them on G3 and G4 Macs vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? Thanks! regrtest.py should be enough. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: I'll crank up some OS X installer builds and run them on G3 and G4 Macs vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 10.3 and above; this is the similar to recent python.org OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Okay, that's awesome. Thanks. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. Okay, that's less than awesome. But still a huge thanks. Then I tried a couple of random floats: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type help, copyright, credits or license for more information. 3.1 -9.255965342383856e+61 1. ^C Terminated -- kill needed I don't suppose it's possible that you could run this under gdb and get a stack trace when it starts looping (assuming that's what's happening)? I think I might have a PPC Mac Mini I can get my hands on, and I'll test there if possible. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jess Austin wrote: What other behavior options besides last-valid-day-of-the-month would you like to see? - Add 30 days to the source date. I'm sure there are others. Followups to python-ideas. ___ 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] 3.1 beta blockers
Alessio Giovanni Baroni wrote: There are some cases of OutOfMemory? On my machine the float-string conversion is all ok. Also 'make test' is all ok. I assume you're talking about issue 5775. I think it's all explained in the bug report. Basically, the float-string conversion can now return an out of memory error, which it could not before. marshal.c's w_object doesn't check for those error conditions. I doubt they'll ever occur in any test, but they need to be handled none the less. It's on my list of things to do in the next week. But if there's anyone who understands the code and would like to take a look, feel free. Eric. 2009/4/21 Benjamin Peterson benja...@python.org mailto:benja...@python.org The first (and only) beta of 3.1 is scheduled for less than 2 weeks away, May 2nd, and is creeping onto the horizon. There are currently 6 blockers: #5692: test_zipfile fails under Windows - This looks like a fairly easy fix. #5775: marshal.c needs to be checked for out of memory errors - Looks like Eric has this one. #5410: msvcrt bytes cleanup - It would be nice to have a Windows expert examine the patch on this issue for correctness. #5786: [This isn't applicable to 3.1] #5783: IDLE cannot find windows chm file - Awaiting a fix to the IDLE or the doc build system. -- Thanks for your work, Benjamin ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alessiogiovanni.baroni%40gmail.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/eric%2Bpython-dev%40trueblade.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] 3.1 beta blockers
Eric Smith wrote: Alessio Giovanni Baroni wrote: There are some cases of OutOfMemory? On my machine the float-string conversion is all ok. Also 'make test' is all ok. I assume you're talking about issue 5775. I think it's all explained in the bug report. Basically, the float-string conversion can now return an out of memory error, which it could not before. marshal.c's w_object doesn't check for those error conditions. I doubt they'll ever occur in any test, but they need to be handled none the less. It's on my list of things to do in the next week. But if there's anyone who understands the code and would like to take a look, feel free. I just fixed it in r71783, so it should be off the list of release blockers. ___ 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] Summary of Python tracker Issues
Mark Dickinson wrote: On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy tjre...@udel.edu wrote: In going through this, I notice a lot of effort by Mark Dickenson and others Many others, but Eric Smith's name needs to be in big lights here. There's no way the short float repr would have been ready for 3.1 if Eric hadn't shown an interest in this at PyCon, and then taken on the major internal replumbing job this entailed for all of Python's string formatting. Not to get too much into a mutual admiration mode, but Mark did the parts involving hard thinking. 3.1. As a certain-to-be beneficiary, I want to thank all who contributed. Glad you like it! Me, too. I think it's going to be great once we get it all straightened out. And I think we're close! Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating PyOS_ascii_formatd
Eric Smith wrote: Assuming that Mark's and my changes in the py3k-short-float-repr branch get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its functionality is largely being replaced by PyOS_double_to_string, which we're introducing on our branch. We've checked the changes in, and everything looks good as far as I can tell. My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in 3.2. Having heard no dissent, I'd like to go ahead and deprecate this API. What are the mechanics of deprecating this? Just documentation, or is there something I should do in the code to generate a warning? Any pointers to examples would be great. The 2.7 situation is tricker, because we're not planning on backporting the short-float-repr work back to 2.7. In 2.7 I guess we'll leave PyOS_ascii_formatd around, unfortunately. I backported the new API to 2.7, so I'll also deprecate PyOS_ascii_formatd there. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating PyOS_ascii_formatd
Benjamin Peterson wrote: 2009/4/24 Eric Smith e...@trueblade.com: My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in 3.2. Having heard no dissent, I'd like to go ahead and deprecate this API. What are the mechanics of deprecating this? Just documentation, or is there something I should do in the code to generate a warning? Any pointers to examples would be great. You can use PyErr_WarnEx(). Thanks. I created issue 5835 to track this. I marked it as a release blocker, but I should have no problem finishing it up this weekend. ___ 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] r71946 - peps/trunk/pep-0315.txt
You might want to note in the PEP that the problem that's being solved is known as the loop and a half problem. http://www.cs.duke.edu/~ola/patterns/plopd/loops.html#loop-and-a-half raymond.hettinger wrote: Author: raymond.hettinger Date: Sun Apr 26 02:34:36 2009 New Revision: 71946 Log: Revive PEP 315. Modified: peps/trunk/pep-0315.txt Modified: peps/trunk/pep-0315.txt == --- peps/trunk/pep-0315.txt (original) +++ peps/trunk/pep-0315.txt Sun Apr 26 02:34:36 2009 @@ -2,9 +2,9 @@ Title: Enhanced While Loop Version: $Revision$ Last-Modified: $Date$ -Author: W Isaac Carroll icarr...@pobox.com -Raymond Hettinger pyt...@rcn.com -Status: Deferred +Author: Raymond Hettinger pyt...@rcn.com +W Isaac Carroll icarr...@pobox.com +Status: Draft Type: Standards Track Content-Type: text/plain Created: 25-Apr-2003 ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two proposed changes to float formatting
Mark Dickinson wrote: I'd like to propose two minor changes to float and complex formatting, for 3.1. I don't think either change should prove particularly disruptive. (1) Currently, '%f' formatting automatically changes to '%g' formatting for numbers larger than 1e50. For example: ... I propose removing this feature for 3.1 I'm +1 on this. I have a suspicion that at least part of the motivation for the '%f' - '%g' switch is that it means the implementation can use a fixed-size buffer. But Eric has fixed this (in 3.1, at least) and the buffer is now dynamically allocated, so this isn't a concern any more. I agree that this is a big part of the reason it was done. There's still some work to be done in the fallback code which we use if we can't use Gay's implementation of _Py_dg_dtoa. But it's reasonably easy to calculate the maximum buffer size needed given the precision, for passing on to PyOS_snprintf. (At least I think that sentence is true, I'll very with Mark offline). Other reasons not to switch from '%f' to '%g' in this way: - the change isn't gentle: as you go over the 1e50 boundary, the number of significant digits produced suddenly changes from 56 to 6; it would make more sense to me if it stayed fixed at 56 sig digits for numbers larger than 1e50. This is the big reason for me. - float formatting is already quite complicated enough; no need to add to the mental complexity And this, too. (2) complex str and repr don't behave like float str and repr, in that the float version always adds a trailing '.0' (unless there's an exponent), but the complex version doesn't: ... I propose changing the complex str and repr to behave like the float version. That is, repr(4. + 10.j) should be (4.0 + 10.0j) rather than (4+10j). I'm +0.5 on this. I'd probably be +1 if I were a big complex user. Also, I'm not sure about the spaces around the sign. If we do want the spaces there, we can get rid of Py_DTSF_SIGN, since that's the only place it's used and we won't be able to use it for complex going forward. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two proposed changes to float formatting
Mark Dickinson wrote: (1) Currently, '%f' formatting automatically changes to '%g' formatting for numbers larger than 1e50. For example: '%f' % 2**166. '93536104789177786765035829293842113257979682750464.00' '%f' % 2**167. '1.87072e+50' I propose removing this feature for 3.1 I don't think we've stated it on this discussion, but I know from private email with Mark that his proposal is for both %-formatting and for float.__format__ to have this change. I just want to get it on the record here. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
I couldn't figure out a way to get rid of it short of multi-#including templates and playing with the C preprocessor, however, and have the nagging feeling the latter would be frowned upon by the maintainers. Not sure if this is exactly what you mean, but look at Objects/stringlib. str.format() and unicode.format() share the same implementation, using stringdefs.h and unicodedefs.h. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed: add support for UNC paths to all functions in ntpath
Michael Foord wrote: Larry Hastings wrote: I've written a patch for Python 3.1 that changes os.path so it handles UNC paths on Windows: http://bugs.python.org/issue5799 +1 for the feature. I have to deal with Windows networks from time to time and this would be useful. +1 from me, too. I haven't looked at the implementation, but for sure the feature would be welcome. In the interests of full disclosure: I submitted a patch providing this exact behavior just over ten years ago. GvR accepted it into Python 1.5.2b2 (marked *EXPERIMENTAL*) and removed it from 1.5.2c1. In the intervening decade, two highly relevant things have happened: * Python no longer uses ntpath for os.path on Cygwin. Instead it uses posixpath. * Cygwin removed the //a/foo drive letter hack. In fact, I believe it now support UNC paths. Therefore this patch will have no effect on Cygwin users. Yes, cygwin supports UNC paths with //host/share, and they use /cygdrive/a, etc., to refer to physical drives. It's been that way for as long as I recall, at least 7 years. ___ 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] svn down?
When checking in, I get: Transmitting file data .svn: Commit failed (details follow): svn: Can't create directory '/data/repos/projects/db/transactions/72186-1.txn': Read-only file system With 'svn up', I get: svn: Can't find a temporary directory: Internal error ___ 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] Changing float.__format__
In issue 5920, Mark Dickinson raises an issue having to do with float.__format__ and how it handles the default format presentation type (that is, none of 'f', 'g', or 'e') versus how str() works on floats: http://bugs.python.org/issue5920 I agree with him that the current behavior is confusing and should be changed. I'm going to make this change, unless anyone objects. Please comment on the issue itself if you have any feedback. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed: add support for UNC paths to all functions in ntpath
Mark Hammond wrote: Is that enough consensus for it to go in? If so, are there any core developers who could help me get it in before the 3.1 feature freeze? The patch should be in good shape; it has unit tests and updated documentation. I've taken the liberty of explicitly CCing Martin just incase he missed the thread with all the noise regarding PEP383. If there are no objections from Martin or anyone else here, please feel free to assign it to me (and mail if I haven't taken action by the day before the beta freeze...) Mark: I've reviewed this and it looks okay to me. It passes all the tests on Windows and Linux. But if you could take a look at it before the release tomorrow, I'd appreciate it. I feel good enough about it to check it in if no one else gets to it. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [Fwd: [Python-checkins] r72331 - python/branches/py3k/Modules/posixmodule.c]
Modules/posixmodule.c now compiles for me, but I get a Bus Error in test_lchflags when running test_posixmodule on Mac OS X 10.5. I'll open a release blocker bug on this. Original Message Subject: [Python-checkins] r72331 - python/branches/py3k/Modules/posixmodule.c Date: Tue, 5 May 2009 15:07:31 +0200 (CEST) From: eric.smith python-check...@python.org To: python-check...@python.org Author: eric.smith Date: Tue May 5 15:07:30 2009 New Revision: 72331 Log: Added missing semicolon. Modified: python/branches/py3k/Modules/posixmodule.c Modified: python/branches/py3k/Modules/posixmodule.c == --- python/branches/py3k/Modules/posixmodule.c (original) +++ python/branches/py3k/Modules/posixmodule.c Tue May 5 15:07:30 2009 @@ -1928,7 +1928,7 @@ if (!PyArg_ParseTuple(args, Oi:lchmod, PyUnicode_FSConverter, opath, i)) return NULL; - path = bytes2str(opath, 1) + path = bytes2str(opath, 1); Py_BEGIN_ALLOW_THREADS res = lchmod(path, i); Py_END_ALLOW_THREADS ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] typo in 8.1.3.1. Format Specification Mini-Language?
Neal Becker wrote: format_spec ::= [[fill]align][sign][#][0][width][.precision][type] The precision is ignored for integer values. In [36]: '%3x' % 10 Out[36]: ' a' In [37]: '%.3x' % 10 Out[37]: '00a' Apparently, precision is _not_ ignored? That section is talking about this: format(10, '.3x') Traceback (most recent call last): File stdin, line 1, in module ValueError: Precision not allowed in integer format specifier ___ 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] typo in 8.1.3.1. Format Specification Mini-Language?
Eric Smith wrote: Neal Becker wrote: format_spec ::= [[fill]align][sign][#][0][width][.precision][type] The precision is ignored for integer values. In [36]: '%3x' % 10 Out[36]: ' a' In [37]: '%.3x' % 10 Out[37]: '00a' Apparently, precision is _not_ ignored? That section is talking about this: format(10, '.3x') Traceback (most recent call last): File stdin, line 1, in module ValueError: Precision not allowed in integer format specifier So I guess it shouldn't say is ignored, it should be is not allowed. ___ 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] py3k build broken
Tarek:
With you ARFLAGS change, I now get the following error on a 32 bit
Fedora 6 box. I've done make distclean and ./configure:
$ make
...
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -I./Modules/_io -c
./Modules/_io/textio.c -o Modules/textio.o
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -I./Modules/_io -c
./Modules/_io/stringio.c -o Modules/stringio.o
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/zipimport.c -o
Modules/zipimport.o
./Modules/zipimport.c: In function ‘get_module_code’:
./Modules/zipimport.c:1132: warning: format ‘%c’ expects type ‘int’, but
argument 3 has type ‘long int’
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/symtablemodule.c
-o Modules/symtablemodule.o
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/xxsubtype.c -o
Modules/xxsubtype.o
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -DSVNVERSION=\`LC_ALL=C
svnversion .`\ -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython3.1.a
ar @ARFLAGS@ libpython3.1.a Modules/getbuildinfo.o
ar: illegal option -- @
Usage: ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV]
[member-name] [count] archive-file file...
ar -M [mri-script]
commands:
d- delete file(s) from the archive
m[ab]- move file(s) in the archive
p- print file(s) found in the archive
q[f] - quick append file(s) to the archive
r[ab][f][u] - replace existing or insert new file(s) into the archive
t- display contents of archive
x[o] - extract file(s) from the archive
command specific modifiers:
[a] - put file(s) after [member-name]
[b] - put file(s) before [member-name] (same as [i])
[N] - use instance [count] of name
[f] - truncate inserted file names
[P] - use full path names when matching
[o] - preserve original dates
[u] - only replace files that are newer than current archive
contents
generic modifiers:
[c] - do not warn if the library had to be created
[s] - create an archive index (cf. ranlib)
[S] - do not build a symbol table
[v] - be verbose
[V] - display the version number
@file - read options from file
emulation options:
No emulation specific options
ar: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32
elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core
make: *** [libpython3.1.a] Error 1
___
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] py3k build broken
Tarek Ziadé wrote: On Thu, May 7, 2009 at 11:36 PM, Eric Smith e...@trueblade.com wrote: With you ARFLAGS change, I now get the following error on a 32 bit Fedora 6 box. I've done make distclean and ./configure: Sorry yes, I am on it now, the produced Makefile is broken, until then you can change it ... No problem. I'll wait. ___ 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] py3k build broken
Tarek Ziadé wrote: I have fixed configure by runing autoconf, everything should be fine now And indeed, it's working fine now, thanks. Sorry for the inconvenience. Not a problem. Anyone who volunteers for autoconf work gets a free pass from me. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
Antoine Pitrou wrote: Yes, I realized that's one of the problems with this proposal. If we had to maintain more than one stable branch, it would become a burden. Agreed. And since we have 2.x and 3.x now, we already have that problem. I'd like to an acceleration of release schedules (if it even happens) come after 2.x is retired. ___ 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] r72995 - in python/branches/py3k: Doc/library/contextlib.rst Doc/whatsnew/3.1.rst Lib/contextlib.py Lib/test/test_contextlib.py Misc/NEWS
raymond.hettinger wrote: Author: raymond.hettinger Date: Fri May 29 00:20:03 2009 New Revision: 72995 Log: Deprecate contextlib.nested(). The with-statement now provides this functionality directly. Modified: python/branches/py3k/Doc/library/contextlib.rst python/branches/py3k/Doc/whatsnew/3.1.rst python/branches/py3k/Lib/contextlib.py python/branches/py3k/Lib/test/test_contextlib.py python/branches/py3k/Misc/NEWS Shouldn't the test cases exist as long as contextlib.nested still exists? We want to make sure it works, after all. I think they should be removed only when .nested is itself deleted. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
I'm against syntax for this, for all the reasons stated by others.
Jerry Chen wrote:
Just one last note: I think my end goal here was to preserve the
visual clarity and separation between format string and format
parameters, as I much prefer:
%s %s %s % (1, 2, 3)
over
{0} {1} {2}.format(1, 2, 3)
If it helps, in 3.1 and 2.7 this can be written as
{} {} {}.format(1, 2, 3)
I'm not sure it helps for visual clarity, but it definitely makes the
typing easier for simple uses.
The former is a style I've grown accustomed to, and if % is indeed
being slated for removal in Python 3.2, then I will miss it sorely
(or... just get over it).
I've basically come to accept that %-formatting can never go away,
unfortunately. There are too many places where %-formatting is used, for
example in logging Formatters. %-formatting either has to exist or it
has to be emulated.
Although if anyone has any suggestions for migrating uses like that, I'm
interested.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Antoine Pitrou wrote: Paul Moore p.f.moore at gmail.com writes: I have no answer here. But I think we need feedback from the people who will ultimately be building bdist_xxx formats - Debian packagers, people wrting alternate RPM builders, etc. I think any bdist_xxx command which targets externally handled package formats (rpm, deb, msi, etc.) shouldn't generate RECORD. If you install with rpm or dpkg, you will uninstall with the same tool, won't you? I agree with this. For RPM's, there's a whole other database of what files were installed. Is it really the intent that a file will be managed by multiple different installers? That I can install with RPM but remove with some python-installer (or other) tool? That way lies madness. In fact, I see RECORD as an installer-specific detail that doesn't need to be standardized at all. For bdist_rpm (which I'm contemplating taking over, but no promises), the only thing that needs to be done with the metadata is be able to build a .spec file. Once the .spec file is generated, rpmbuild (or equivalent) will produce the .rpm files. I image that .deb's are similar, but I'm no expert. Which brings up the static metadata argument I was making at PyCon. I want there to be enough static metadata that the new bdist_rpm can read so that it produces a well-behaved .spec file. I need to know the intent of some of the files (which are documentation, which are config files, which are scripts, which are libraries, etc.) and not much else. I envision the new bdist_rpm as a standalone tool, not a distutils extension. Bottom line - Is RECORD to be created on the target machine at install time, or must it be relocatable? This is quite an uninformed opinion, but a relocatable RECORD looks like a can of worms to me. Agreed. As for creating RECORD at install time, I don't understand the argument about duplicate code. Distutils can provide useful primitives for generating RECORD, so that interested subcommands don't have a lot of additional work to do. I envision a distlib that contains new support code that's not part of the current distutils morass. ___ 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] PEP 376 - Open questions
P.J. Eby wrote: At 08:59 AM 7/8/2009 -0400, Eric Smith wrote: I agree with this. For RPM's, there's a whole other database of what files were installed. Is it really the intent that a file will be managed by multiple different installers? That I can install with RPM but remove with some python-installer (or other) tool? That way lies madness. In fact, I see RECORD as an installer-specific detail that doesn't need to be standardized at all. This is a misunderstanding. The purpose is to let an *installer* (like easy_install) know that these files belong to some other installer, and not allow overwriting them. That's why there's also an INSTALLER file. I really don't see this use case. Supporting multiple installers for the same file (or even just trying to prevent two installers from writing the same file)? Wouldn't you be better off just saying an installer can't overwrite any existing file? Likewise, I don't see a use case for installing with one installer and uninstalling with another. Put those two together, and the mechanism that an installer uses to record what files it installed is a private implementation detail. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Paul Moore wrote: 2009/7/8 P.J. Eby p...@telecommunity.com: If it were being driven by setuptools, I'd have just implemented it myself and presented it as a fait accompli. I can't speak to Tarek's motives, but I assume that, as stated in the PEP, the primary driver is supporting the distutils being able to uninstall things, and secondarily to allow other tools to be built on top of the API. My understanding is that all of the various distutils PEPs were driven by the packaging summit ay PyCon. The struggle here seems to be to find *anyone* from that summit who will now comment on the discussion :-( I was there, and I've been commenting! There might have been more discussion after the language summit and the one open space event I went to. But the focus as I recall was static metadata and version specification. When I originally brought up static metadata at the summit, I meant metadata describing the sources in the distribution, so that we can get rid of setup.py's. From that metadata, I want to be able to generate .debs, .rpms, .eggs, etc. But I think we've veered into metadata that describes what has been installed. I don't think that's so useful. As I've said, this is private to the installers. If 2 installers want to communicate with each other about what they've installed, then they can agree on that data. I just don't find it generally useful for all installers, and therefore not useful for distutils. I'd like to get back to the metadata that describes the source files. That's where the real value lies, in my opinion. I'll try and work on a post to distutils-sig explaining my thinking. ___ 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
