[Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]
On Fri, 10 Feb 2006 21:35:26 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
On Sat, 11 Feb 2006 05:08:09 + (UTC), Neil Schemenauer [EMAIL
PROTECTED] The backwards compatibility problems *seem* to be relatively
minor.
I only found one instance of breakage in the standard library. Note
that my patch does not change PyObject_Str(); that would break
massive amounts of code. Instead, I introduce a new function:
PyString_New(). I'm not crazy about the name but I couldn't think
of anything better.
On 2/10/06, Bengt Richter [EMAIL PROTECTED] wrote:
Should this not be coordinated with PEP 332?
Probably.. But that PEP is rather incomplete. Wanna work on fixing that?
I'd be glad to add my thoughts, but first of course it's Skip's PEP,
and Martin casts a long shadow when it comes to character coding issues
that I suspect will have to be considered.
(E.g., if there is a b'...' literal for bytes, the actual characters of
the source code itself that the literal is being expressed in could be ascii
or latin-1 or utf-8 or utf16le a la Microsoft, etc. UIAM, I read that the source
is at least temporarily normalized to Unicode, and then re-encoded (except now
for string literals?) per coding cookie or other encoding inference. (I may be
out of date, gotta catch up).
If one way or the other a string literal is in Unicode, then presumably so is
a byte string b'...' literal -- i.e. internally ub'...' just before
being turned into bytes.
Should that then be an internal straight ub'...'.encode('byte') with default
ascii + escapes
for non-ascii and non-printables, to define the full 8 bits without encoding
error?
Should unicode be encodable into byte via a specific encoding? E.g.,
u'abc'.encode('byte','latin1'),
to distinguish producing a mutable byte string vs an immutable str type as with
u'abc'.encode('latin1').
(but how does this play with str being able to produce unicode? And when do
these changes happen?)
I guess I'm getting ahead of myself ;-)
So I would first ask Skip what he'd like to do, and Martin for some hints on
reading, to avoid
going down paths he already knows lead to brick walls ;-) And I need to think
more about PEP 349.
I would propose to do the reading they suggest, and edit up a new version of
pep-0332.txt
that anyone could then improve further. I don't know about an early deadline. I
don't want
to over-commit, as time and energies vary. OTOH, as you've noticed, I could be
spending my
time more effectively ;-)
I changed the thread title, and will wait for some signs from you, Skip,
Martin, Neil, and I don't
know who else might be interested...
Regards,
Bengt Richter
___
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] Baffled by PyArg_ParseTupleAndKeywords modification
Greg Ewing wrote: FWIW, Annex D also defines these features as deprecated: - the use of static for objects in namespace scope (AFAICT including C file-level static variables and functions) - C library headers (i.e. stdio.h) Things like this are really starting to get on my groat. It used to be that C++ was very nearly a superset of C, so it was easy to write code that would compile as either. But C++ seems to be evolving into a different language altogether. Not at all. People appear to completely fail to grasp the notion of deprecated in this context. It just means it may go away in a future version, implying that the rest of it may *not* go away in a future version. That future version might get published in 2270, when everybody has switched to C++, and compatibility with C is no longer required. So the compiler is wrong for warning about it (or the user is wrong for asking to get warned), and you are wrong for getting upset about this. (And an obnoxiously authoritarian one at that. If I want to write some C++ code that uses stdio because I happen to like it better, why the heck shouldn't I be allowed to? It's MY program, not the C++ standards board's!) Again, you are misunderstanding what precisely is deprecated. Sure you can still use stdio, and it is never going away (it isn't deprecated). However, you have to spell the header as #include cstdio and then refer to the functions as std::printf, std::stderr, etc. What is really being deprecated here is the global namespace. That's also the reason to deprecate file-level static: you should use anonymous namespaces instead. (Also, just in case this is misunderstood again: it is *not* that programs cannot put stuff in the global namespace anymore. It's just that the standard library should not put stuff in the global namespace). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Bengt Richter wrote: Would it make sense to use a typedef for readability's sake? E.g., typedef const char * p_text_literal; and then use p_text_literal, const p_text_literal * in the signature, for read-only access to the data? (hope I got that right). (also testing whether I have been redirected to /dev/null ;-) Nearly. Please try your proposals out in a sandbox before posting. How does this contribute to solving the PyArg_ParseTupleAndKeywords issue? Readability is not the problem that puzzled Jack. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
On Fri, 10 Feb 2006 14:33:08 +0100, Armin Rigo [EMAIL PROTECTED] wrote:
Hi Nick,
On Fri, Feb 10, 2006 at 11:21:52PM +1000, Nick Coghlan wrote:
Do they really need anything more sophisticated than:
def __repr__(self):
return %s(%r) % (type(self).__name__, self._subiter)
(modulo changes in the format of arguments, naturally. This simple one would
work for things like enumerate and reversed, though)
My goal here is not primarily to help debugging, but to help playing
around at the interactive command-line. Python's command-line should
not be dismissed as useless for real programmers; I definitely use it
all the time to try things out. It would be nicer if all these
iterators I'm not familiar with would give me a hint about what they
actually return, instead of:
itertools.count(17)
count(17) # yes, thank you, not very helpful
enumerate(spam)
enumerate(spam) # with your proposed extension -- not better
However, if this kind of goal is considered not serious enough for
adding a private special method, then I'm fine with trying out a fishing
approach.
For enhancing interactive usage, how about putting the special info and smarts
in help?
Or even a specialized part of help, e.g.,
help.explain(itertools.count(17))
or maybe
help.explore(itertools.count(17))
leading to an interactive prompt putting handy cmdwords in a line to get
easily to type, mro, non-underscore methods, attribute name list, etc.
E.g. I often find myself typing stuff like
[x for x in dir(obj) if not x.startswith('_')]
or
[k for k,v in type(obj).__dict__.items() if callable(v) and not
k.startswith('_')]
that I would welcome being able to do easily with a specialized
help.plaindir(obj)
or help.plainmethods(obj) or help.mromethods(obj) etc.
Hm, now that I think of it, I guess I could do stuff like that in site.py, since
help.plaindir = lambda x: sorted([x for x in dir(x) if not
x.startswith('_')])
help.plaindir(int)
[]
help.plaindir([])
['append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse',
'sort']
But some kind of standards would probably be nice for everyone if they like the
general idea.
I'll leave it to someone else as to whether and where a thread re help
enhancements
might be ok.
My .02USD ;-)
Regards,
Bengt Richter
___
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] The decorator(s) module
Hi, it has been proposed before, but there was no conclusive answer last time: is there any chance for 2.5 to include commonly used decorators in a module? Of course not everything that jumps around should go in, only pretty basic stuff that can be widely used. Candidates are: - @decorator. This properly wraps up a decorator function to change the signature of the new function according to the decorated one's. - @contextmanager, see PEP 343. - @synchronized/@locked/whatever, for thread safety. - @memoize - Others from wiki:PythonDecoratorLibrary and Michele Simionato's decorator module at http://www.phyast.pitt.edu/~micheles/python/documentation.html. Unfortunately, a @property decorator is impossible... regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] release plan for 2.5 ?
Guido van Rossum wrote: Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: alpha 1: May 2006 alpha 2: June 2006 beta 1: July 2006 beta 2: August 2006 rc 1:September 2006 final: September 2006 ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. I am not experienced in releasing, but with the multitude of new things introduced in Python 2.5, could it be a good idea to release an early alpha not long after all (most of?) the desired features are in the trunk? That way people would get to testing sooner and the number of non-obvious bugs may be reduced (I'm thinking of the import PEP, the implementation of which is bound to be hairy, or with in its full extent). Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] release plan for 2.5 ?
Guido van Rossum wrote: - setuplib? Wouldn't it make sense to add this to the 2.5 stdlib? If you mean setuptools, I'm a big +1 (if it's production-ready by that time). Together with a whipped up cheese shop we should finally be able to put up something equal to cpan/rubygems. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The decorator(s) module
Hi, it has been proposed before, but there was no conclusive answer last time: is there any chance for 2.5 to include commonly used decorators in a module? Of course not everything that jumps around should go in, only pretty basic stuff that can be widely used. Candidates are: - @decorator. This properly wraps up a decorator function to change the signature of the new function according to the decorated one's. - @contextmanager, see PEP 343. - @synchronized/@locked/whatever, for thread safety. - @memoize - Others from wiki:PythonDecoratorLibrary and Michele Simionato's decorator module at http://www.phyast.pitt.edu/~micheles/python/documentation.html. Unfortunately, a @property decorator is impossible... regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 338 - Executing Modules as Scripts
I finally finished updating PEP 338 to comply with the flexible importing system in PEP 302. The result is a not-yet-thoroughly-tested module that should allow the -m switch to execute any module written in Python that is accessible via an absolute import statement. The PEP now uses runpy for the module name, and run_module for the function used to locate and execute scripts. There's probably some discussion to be had in relation to the Design Decisions section of the PEP, relating to the way I wrote the module (the handling of locals dictionaries in particular deserves consideration). Tracker items for the runpy module [1] and its documentation [2] are on Sourceforge (the interesting parts of the documentation are in the PEP, so I suggest reading that rather than the LaTex version). Still missing from the first tracker item are a patch to update '-m' to invoke the new module and some unit tests (the version on SF has only had ad hoc testing from the interactive prompt at this stage). I hope to have those up shortly, though. Cheers, Nick. [1] http://www.python.org/sf/1429601 [2] http://www.python.org/sf/1429605 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] release plan for 2.5 ?
Guido van Rossum wrote: PEP 338 - support -m for modules in packages. I believe Nick Coghlan is close to implementing this. I'm fine with accepting it. I just checked in a new version of PEP 338 that cleans up the approach so that it provides support for any PEP 302 compliant packaging mechanism as well as normal filesystem packages. I've started a new thread for the discussion: PEP 338 - Executing Modules as Scripts Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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 decorator(s) module
On Fri, Feb 10, 2006 at 10:32:23PM +0100, Georg Brandl wrote: Unfortunately, a @property decorator is impossible... Depends. You can do, e.g., def propertydef(propertydesc): data = propertydesc() if not data: raise ValueError, Invalid property descriptors getter, setter, deller = (data + (None, None))[:3] return property(fget=getter, fset=setter, fdel=deller, doc=propertydesc.__doc__) and use it like: class X(object): def __init__(self): self._prop = None @propertydef def prop(): Public, read-only access to self._prop def getter(self): return self._prop return (getter,) @propertydef def rwprop(): Public read-write access to self._prop def getter(self): return self._prop def setter(self, val): self._prop = val def deller(self): self._prop = None return (getter, setter, deller) @propertydef def hiddenprop(): Public access to a value stored in a closure prop = [None] def getter(self): return prop[0] def setter(self, val): prop[0] = val def deller(self): prop[0] = None return (getter, setter, deller) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Baffled by PyArg_ParseTupleAndKeywords modification
On Fri, 10 Feb 2006 18:02:03 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
Perhaps someone with better C/C++ standards chops can explain.
Please take a look at this code:
void foo(const char** x, const char*s)
{
x[0] = s;
}
void bar()
{
char *kwds[] = {0};
const char *s = Text;
foo(kwds, s);
kwds[0][0] = 't';
}
If it was correct, you would be able to modify the const char
array in the string literal, without any compiler errors. The
assignment
x[0] = s;
is kosher, because you are putting a const char* into a
const char* array, and the assigment
kwds[0][0] = 't';
is ok, because you are modifying a char array. So the place
where it has to fail is the passing of the pointer-pointer.
Will a typedef help?
martin.c ---
#include cstdio
typedef const char *ptext;
void foo(ptext *kw)
{
const char *s = Text;
ptext *p;
for(p=kw;*p;p++){ printf(foo:%s\n, *p);}
kw[0] = s;
for(p=kw;*p;p++){ printf(foo2:%s\n, *p);}
kw[0][0] = 't'; /* comment this out and it compiles and runs */
for(p=kw;*p;p++){ printf(foo3:%s\n, *p);}
}
int main()
{
char *kwds[] = {Foo,Bar,0};
char **p;
for(p=kwds;*p;p++){ printf(%s\n, *p);}
foo(kwds);
for(p=kwds;*p;p++){ printf(%s\n, *p);}
}
---
[12:32] C:\pywk\pydevcl martin.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
martin.c
martin.c(10) : error C2166: l-value specifies const object
But after commenting out:
[12:32] C:\pywk\pydevcl martin.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
martin.c
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:martin.exe
martin.obj
[12:34] C:\pywk\pydevmartin
Foo
Bar
foo:Foo
foo:Bar
foo2:Text
foo2:Bar
foo3:Text
foo3:Bar
Text
Bar
Regards,
Bengt Richter
___
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] Baffled by PyArg_ParseTupleAndKeywords modification
Bengt Richter wrote: Will a typedef help? A typedef can never help. It is always possible to reformulate a program using typedefs to one that doesn't use typedefs. Compiling your program with the const modification line removed gives martin.c: In function 'int main()': martin.c:18: error: invalid conversion from 'char**' to 'const char**' martin.c:18: error: initializing argument 1 of 'void foo(const char**)' Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The decorator(s) module
Georg Brandl [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]:
Unfortunately, a @property decorator is impossible...
It all depends what you want (and whether you want the implementation to be
portable to other Python implementations). Here's one possible but not
exactly portable example:
from inspect import getouterframes, currentframe
import unittest
class property(property):
@classmethod
def get(cls, f):
locals = getouterframes(currentframe())[1][0].f_locals
prop = locals.get(f.__name__, property())
return cls(f, prop.fset, prop.fdel, prop.__doc__)
@classmethod
def set(cls, f):
locals = getouterframes(currentframe())[1][0].f_locals
prop = locals.get(f.__name__, property())
return cls(prop.fget, f, prop.fdel, prop.__doc__)
@classmethod
def delete(cls, f):
locals = getouterframes(currentframe())[1][0].f_locals
prop = locals.get(f.__name__, property())
return cls(prop.fget, prop.fset, f, prop.__doc__)
class PropTests(unittest.TestCase):
def test_setgetdel(self):
class C(object):
def __init__(self, colour):
self._colour = colour
@property.set
def colour(self, value):
self._colour = value
@property.get
def colour(self):
return self._colour
@property.delete
def colour(self):
self._colour = 'none'
inst = C('red')
self.assertEquals(inst.colour, 'red')
inst.colour = 'green'
self.assertEquals(inst._colour, 'green')
del inst.colour
self.assertEquals(inst._colour, 'none')
if __name__=='__main__':
unittest.main()
___
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] Pervasive socket failures on Windows
On 10-feb-2006, at 23:49, Martin v. Löwis wrote: Tim Peters wrote: I don't know. Of course it misses similar new tests added to _ssl.c (see the msg that started this thread), so it spreads beyond just this. Does it do the right thing for Windows variants like Cygwin, and OS/2? Don't know. I see. How does Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE help here? Does defining it in PC/pyconfig.h do the right thing? I guess I'm primarily opposed to the visual ugliness of the define. Why does it spell out can be, but abbreviates greater than or equal to? What about Py_CHECK_FD_SETSIZE? If I understand this discussion correctly that code that would be conditionalized using this define is the IS_SELECTABLE macro in selectmodule.c and very simular code in other modules. I'd say that calling the test _Py_IS_SELECTABLE and putting it into pyport.h as Tim mentioned in an aside seems to be a good solution. At the very least it is a lot nicer than defining a very long name in pyconfig.h and then having very simular code in several #if blocks. Ronald Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Greg Ewing wrote the following on 2006-02-10 at 16:20 PST: === Although print may become a function in 3.0, so that this particular example would no longer be a problem. === You can always make your own Print function. The pyNMS framework adds many new builtins, as well as a Print function, when it is installed. http://svn.dartworks.biz/svn/repos/pynms/trunk/lib/nmsbuiltins.py -- -- ~ Keith Dart [EMAIL PROTECTED] public key: ID: 19017044 http://www.dartworks.biz/ = signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pervasive socket failures on Windows
Ronald Oussoren wrote: If I understand this discussion correctly that code that would be conditionalized using this define is the IS_SELECTABLE macro in selectmodule.c and very simular code in other modules. I'd say that calling the test _Py_IS_SELECTABLE and putting it into pyport.h as Tim mentioned in an aside seems to be a good solution. At the very least it is a lot nicer than defining a very long name in pyconfig.h and then having very simular code in several #if blocks. For the moment, I have committed Tim's original proposal. Moving the macro into pyport.h could be done in addition. That should be done only if selectmodule is also adjusted; this currently tests for _MSC_VER. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 - Executing Modules as Scripts
Nick Coghlan wrote: The PEP now uses runpy for the module name, and run_module for the function used to locate and execute scripts. There's probably some discussion to be had in relation to the Design Decisions section of the PEP, relating to the way I wrote the module (the handling of locals dictionaries in particular deserves consideration). Huh. Speaking of not-thoroughly-tested, exec + function code objects doesn't seem to work anything like I expected, so some of my assumptions in the PEP relating to the way the locals dictionary should be handled are clearly wrong. As I discovered, the name binding operations in a function code object have no effect whatsoever on the dictionaries passed to an invocation of exec. I'll update the PEP to drop run_function_code, and make run_code a simple wrapper around the exec statement that always returns the dictionary used as 'locals' (which may happen to be the same dictionary used as 'globals'). If the way exec handles function code objects and provision of a locals dictionary ever changes, then run_code will pick up the new semantics automatically. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] How to get the Python-2.4.2 sources from SVN?
It isn't completely clear which branch or tag to get, and Google turned up no obvious documentation. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.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] How to get the Python-2.4.2 sources from SVN?
David Abrahams wrote: It isn't completely clear which branch or tag to get, and Google turned up no obvious documentation. http://svn.python.org/projects/python/tags/r242/ Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to get the Python-2.4.2 sources from SVN?
Dave It isn't completely clear which branch or tag to get, and Google Dave turned up no obvious documentation. On subversion, you want releaseXY-maint for the various X.Y releases. For 2.4.2, release24-maint is what you want, though it may have a few bug fixes since 2.4.2 was released. With CVS I used to use cvs log README to see what all the tags and branches were. I don't know what the equivalent svn command is. Skip ___ 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] To know how to set pythonpath
I am a newbe to python. While I am running some scripts it reports some errors because of PYTHONPATH variable. Can you send me information of how to set PYTHONPATH. I am using python 2.1.3 on aix 5.2. Regards -Raveendrababu ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 10 Feb 2006, at 12:45, Nick Coghlan wrote:An alternative would be to call it "__discrete__", as that is the key characteristic of an indexing type - it consists of a sequence of discrete values that can be isomorphically mapped to the integers. Another alternative: __as_ordinal__. Wikipedia describes ordinals as "numbers used to denote the position in an ordered sequence" which seems a pretty precise description of the intended result. The "as_" prefix also captures the idea that this should be a lossless conversion.Mark Russell___ 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] How to get the Python-2.4.2 sources from SVN?
On Sat, Feb 11, 2006 at 09:10:41AM -0600, [EMAIL PROTECTED] wrote: Dave It isn't completely clear which branch or tag to get, and Google Dave turned up no obvious documentation. On subversion, you want releaseXY-maint for the various X.Y releases. For 2.4.2, release24-maint is what you want, though it may have a few bug fixes since 2.4.2 was released. With CVS I used to use cvs log README to see what all the tags and branches were. I don't know what the equivalent svn command is. The 'cvs log' trick only works if the file you log is actually part of the branch. Not an issue with Python or any other project that always branches sanely, fortunately, but there's always wackos out there ;) You get the list of branches in SVN with: svn ls http://svn.python.org/projects/python/branches/ And similarly, tags with: svn ls http://svn.python.org/projects/python/tags -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] How to get the Python-2.4.2 sources from SVN?
[EMAIL PROTECTED] wrote: On subversion, you want releaseXY-maint for the various X.Y releases. For 2.4.2, release24-maint is what you want, though it may have a few bug fixes since 2.4.2 was released. With CVS I used to use cvs log README to see what all the tags and branches were. I don't know what the equivalent svn command is. The easiest is to open either http://svn.python.org/projects/python/tags/ or http://svn.python.org/projects/python/branches/ in a web browser. If you want to use the subversion command line, do svn ls http://svn.python.org/projects/python/tags/ Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Where to put post-it notes?
I just updated the general copyright notice to include the year 2006. This is scattered in at least 6 files (I found that many searching for 2004 and 2005) which would be handy to record somewhere so that next year it's easier. Where does this belong? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] To know how to set pythonpath
On Fri, Feb 10, 2006, M, Raveendra Babu (STSD) wrote: I am a newbe to python. While I am running some scripts it reports some errors because of PYTHONPATH variable. Can you send me information of how to set PYTHONPATH. I am using python 2.1.3 on aix 5.2. Sorry, this is the wrong place. Please use another place, such as comp.lang.python, and read http://www.catb.org/~esr/faqs/smart-questions.html -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ 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] Baffled by PyArg_ParseTupleAndKeywords modification
On Sat, Feb 11, 2006, Martin v. L?wis wrote: Not at all. People appear to completely fail to grasp the notion of deprecated in this context. It just means it may go away in a future version, implying that the rest of it may *not* go away in a future version. That future version might get published in 2270, when everybody has switched to C++, and compatibility with C is no longer required. Just for the clarification of those of us who are not C/C++ programmers, are you saying that this is different from the meaning in Python, where deprecated means that something *IS* going away? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ 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 338 - Executing Modules as Scripts
On 2/11/06, Nick Coghlan [EMAIL PROTECTED] wrote: I finally finished updating PEP 338 to comply with the flexible importing system in PEP 302. The result is a not-yet-thoroughly-tested module that should allow the -m switch to execute any module written in Python that is accessible via an absolute import statement. Does this implementation resolve http://www.python.org/sf/1250389 as well? A reading of the PEP would seem to imply that it does, but the SF patches you mention don't include any changes to the core, so I'm not sure... Paul. ___ 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] file.next() vs. file.readline()
On Thu, Jan 05, 2006 at 07:30:08PM +0100, Thomas Wouters wrote: On Wed, Jan 04, 2006 at 10:10:07AM -0800, Guido van Rossum wrote: I'd say go right ahead and submit a change to SF (and then after it's reviewed you can check it in yourself :-). http://www.python.org/sf?id=1397960 So, any objections to me checking this in? It doesn't break anything that wasn't already broken, but neither does it fix it; it just makes the error more apparent. I don't think it'd be a bugfix candidate, since it changes the effect of the error (rather than silently delivering data out of order, it complains.) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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 338 - Executing Modules as Scripts
Paul Moore wrote: On 2/11/06, Nick Coghlan [EMAIL PROTECTED] wrote: I finally finished updating PEP 338 to comply with the flexible importing system in PEP 302. The result is a not-yet-thoroughly-tested module that should allow the -m switch to execute any module written in Python that is accessible via an absolute import statement. Does this implementation resolve http://www.python.org/sf/1250389 as well? A reading of the PEP would seem to imply that it does, but the SF patches you mention don't include any changes to the core, so I'm not sure... It will. I haven't updated the command line switch itself yet, so you'd need to do -m runpy whatever. I do plan on fixing the switch, but at the moment there's a bug in the module's handling of nested packages, so I want to sort that out first. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Baffled by PyArg_ParseTupleAndKeywords modification
On Sat, 11 Feb 2006 14:14:00 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: Bengt Richter wrote: Will a typedef help? A typedef can never help. It is always possible to reformulate a program using typedefs to one that doesn't use typedefs. I realize that's true for a correct compiler, and should have reflected that you aren't just trying to appease a particular possibly quirky one. Compiling your program with the const modification line removed gives martin.c: In function 'int main()': martin.c:18: error: invalid conversion from 'char**' to 'const char**' martin.c:18: error: initializing argument 1 of 'void foo(const char**)' Sorry, I should have tried it with gcc, which does complain: [07:16] /c/pywk/pydevgcc martin.c martin.c: In function `main': martin.c:19: warning: passing arg 1 of `foo' from incompatible pointer type also g++, but not just warning (no a.exe generated) [07:16] /c/pywk/pydevg++ martin.c martin.c: In function `int main()': martin.c:19: invalid conversion from `char**' to `const char**' [07:17] /c/pywk/pydevgcc -v snip full specs gcc version 3.2.3 (mingw special 20030504-1) But Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 didn't complain. But then it doesn't complain about const char** x either. I wonder if I have complaints accidentally turned off someplace ;-/ Sorry. Regards, Bengt Richter ___ 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 338 - Executing Modules as Scripts
Nick Coghlan wrote: Paul Moore wrote: On 2/11/06, Nick Coghlan [EMAIL PROTECTED] wrote: I finally finished updating PEP 338 to comply with the flexible importing system in PEP 302. The result is a not-yet-thoroughly-tested module that should allow the -m switch to execute any module written in Python that is accessible via an absolute import statement. Does this implementation resolve http://www.python.org/sf/1250389 as well? A reading of the PEP would seem to imply that it does, but the SF patches you mention don't include any changes to the core, so I'm not sure... It will. I haven't updated the command line switch itself yet, so you'd need to do -m runpy whatever. I do plan on fixing the switch, but at the moment there's a bug in the module's handling of nested packages, so I want to sort that out first. OK, nested packages now work right (I'd managed to make the common mistake that's highlighted quite clearly in the docs for __import__). Running from inside a zipfile also appears to be working, but I don't have zlib in my Python 2.5 build to be 100% certain of that (I could check for certain with Python 2.4, but that would involve enough mucking around that I don't want to do it right now). My aim is to have a patch up for the command line switch tomorrow. It shouldn't be too tricky, since it is just a matter of retrieving and calling the function from the module. That should supply the last missing piece for the PEP implementation (aside from figuring out how to integrate my current manual test setup for runpy.run_module into the unit tests - it shouldn't be that hard to create a temp directory and add some files to it, similar to what test_pkg already does). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Where to put post-it notes?
Georg Brandl wrote: I just updated the general copyright notice to include the year 2006. This is scattered in at least 6 files (I found that many searching for 2004 and 2005) which would be handy to record somewhere so that next year it's easier. Where does this belong? PEP 101 maybe? Checking the copyright notices can be done independently of releases, but they should *definitely* be checked before a release goes out. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Where to put post-it notes?
Nick Coghlan wrote: Georg Brandl wrote: I just updated the general copyright notice to include the year 2006. This is scattered in at least 6 files (I found that many searching for 2004 and 2005) which would be handy to record somewhere so that next year it's easier. Where does this belong? PEP 101 maybe? Checking the copyright notices can be done independently of releases, but they should *definitely* be checked before a release goes out. Ah! They were already there. I added two more files. By the way, PEP 101 will need to be rewritten to reflect the move to SVN. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The decorator(s) module
+1, and we could maybe include tail_call_optimized? http://littlelanguages.com/2006/02/tail-call-optimization-as-python.html On 2/11/06, Georg Brandl [EMAIL PROTECTED] wrote: Hi, it has been proposed before, but there was no conclusive answer last time: is there any chance for 2.5 to include commonly used decorators in a module? Of course not everything that jumps around should go in, only pretty basic stuff that can be widely used. Candidates are: - @decorator. This properly wraps up a decorator function to change the signature of the new function according to the decorated one's. - @contextmanager, see PEP 343. - @synchronized/@locked/whatever, for thread safety. - @memoize - Others from wiki:PythonDecoratorLibrary and Michele Simionato's decorator module at http://www.phyast.pitt.edu/~micheles/python/documentation.html. Unfortunately, a @property decorator is impossible... regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com -- Crutcher Dunnavant [EMAIL PROTECTED] littlelanguages.com monket.samedi-studios.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] How to get the Python-2.4.2 sources from SVN?
Thomas Wouters [EMAIL PROTECTED] writes: On Sat, Feb 11, 2006 at 09:10:41AM -0600, [EMAIL PROTECTED] wrote: Dave It isn't completely clear which branch or tag to get, and Google Dave turned up no obvious documentation. On subversion, you want releaseXY-maint for the various X.Y releases. For 2.4.2, release24-maint is what you want, though it may have a few bug fixes since 2.4.2 was released. With CVS I used to use cvs log README to see what all the tags and branches were. I don't know what the equivalent svn command is. The 'cvs log' trick only works if the file you log is actually part of the branch. Not an issue with Python or any other project that always branches sanely, fortunately, but there's always wackos out there ;) You get the list of branches in SVN with: svn ls http://svn.python.org/projects/python/branches/ And similarly, tags with: svn ls http://svn.python.org/projects/python/tags Yes, that's easy enough, but being sure of the meaning of any given tag or branch name is less easy. -- Dave Abrahams Boost Consulting www.boost-consulting.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
[Python-Dev] PEP 351
On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote: [Guido van Rossum] PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? It has at least one anti-champion. I think it is a horrible idea and would like to see it rejected in a way that brings finality. If needed, I can elaborate in a separate thread. Could you please do that? I'd like to understand all of your objections. Thanks! Alex ___ 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] Baffled by PyArg_ParseTupleAndKeywords modification
Hi Tim, On Fri, Feb 10, 2006 at 12:19:01PM -0500, Tim Peters wrote: Oh, who cares? I predict Jack's problem would go away if we changed the declaration of PyArg_ParseTupleAndKeywords to what you intended wink to begin with: PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, ...); Alas, this doesn't make gcc happy either. (I'm trying gcc 3.4.4.) In theory, it prevents the const-bypassing trick showed by Martin, but apparently the C standard (or gcc) is not smart enough to realize that. I don't see a way to spell it in C so that the same extension module compiles with 2.4 and 2.5 without a warning, short of icky macros. A bientot, Armin ___ 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 351
On Feb 11, 2006, at 3:55 PM, Alex Martelli wrote: On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote: [Guido van Rossum] PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? It has at least one anti-champion. I think it is a horrible idea and would like to see it rejected in a way that brings finality. If needed, I can elaborate in a separate thread. Could you please do that? I'd like to understand all of your objections. Thanks! Better yet, add them to the PEP. -Barry ___ 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] Baffled by PyArg_ParseTupleAndKeywords modification
Martin v. Löwis wrote: That future version might get published in 2270, There are *already* differences which make C and C++ annoyingly incompatible. One is the const char * const * issue that appeared here. Another is that it no longer seems to be permissible to forward-declare static things, which has caused me trouble with Pyrex. That's not just a deprecation -- some compilers refuse to compile it at all. Personally I wouldn't mind about these things, as I currently don't care if I never write another line of C++ in my life. But if e.g. Pyrex-generated code is to interoperate with other people's C++ code, I need to worry about these issues. when everybody has switched to C++, and compatibility with C is no longer required. Yeeks, I hope not! The world needs *less* C++, not more... Sure you can still use stdio, and it is never going away (it isn't deprecated). However, you have to spell the header as #include cstdio and then refer to the functions as std::printf, std::stderr, etc. Which makes it a very different language from C in this area. That's my point. Greg ___ 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 351
- Original Message - From: Alex Martelli [EMAIL PROTECTED] To: Raymond Hettinger [EMAIL PROTECTED] Cc: python-dev@python.org Sent: Saturday, February 11, 2006 3:55 PM Subject: PEP 351 On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote: [Guido van Rossum] PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? It has at least one anti-champion. I think it is a horrible idea and would like to see it rejected in a way that brings finality. If needed, I can elaborate in a separate thread. Could you please do that? I'd like to understand all of your objections. Thanks! Here was one email on the subject: http://mail.python.org/pipermail/python-dev/2005-October/057586.html I have a number of comp.lang.python posts on the subject also. The presence of frozenset() tempts this sort of hypergeneralization. The first stumbling block comes with dictionaries. Even if you skip past the question of why you would want to freeze a dictionary (do you really want to use it as a key?), one find that dicts are not naturally freezable -- dicts compare using both keys and values; hence, if you want to hash a dict, you need to hash both the keys and values, which means that the values have to be hashable, a new and suprising requirement -- also, the values cannot be mutated or else an equality comparison will fail when search for a frozen dict that has been used as a key. One person who experimented with an implementation dealt with the problem by recursively freezing all the components (perhaps one of the dict's values is another dict which then needs to be frozen too). Executive summary: freezing dicts is a can of worms and not especially useful. Another thought is that PEP 351 reflects a world view of wanting to treat all containers polymorphically. I would suggest that they aren't designed that way (i.e. you use different methods to add elements to lists, dicts, and sets). Also, it is not especially useful to shovel around mutable containers without respect to their type. Further, even if they were polymorphic and freezable, treating them generically is likely to reflect bad design -- the soul of good programming is the correct choice of appropriate data structures. Another PEP 351 world view is that tuples can serve as frozenlists; however, that view represents a Liskov violation (tuples don't support the same methods). This idea resurfaces and has be shot down again every few months. More important than all of the above is the thought that auto-freezing is like a bad C macro, it makes too much implicit and hides too much -- the supported methods change, there is a issue keeping in sync with the non-frozen original, etc. In my experience with frozensets, I've learned that freezing is not an incidental downstream effect; instead, it is an intentional, essential part of the design and needs to be explicit. If more is needed on the subject, I'll hunt down my old posts and organize them. I hope we don't offer a freeze() builtin. If it is there, it will be tempting to use it and I think it will steer people away from good design and have a net harmful effect. Raymond P.S. The word freezing is itself misleading because it suggests an in-place change. However, it really means that a new object is created (just like tuple(somelist)). ___ 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] Pervasive socket failures on Windows
[Martin v. Löwis] For the moment, I have committed Tim's original proposal. Thank you! I checked, and that fixed all the test failures I was seeing on Windows. Moving the macro into pyport.h could be done in addition. That should be done only if selectmodule is also adjusted; this currently tests for _MSC_VER. It's a nice illustration of why platform-dependent code sprayed across modules sucks, too. Why _MSC_VER instead of MS_WINDOWS? What's the difference, exactly? Who knows? I see that selectmodule.c has this comment near the top: Under BeOS, we suffer the same dichotomy as Win32; sockets can be anything = 0. but there doesn't appear to be any _code_ matching that comment in that module -- unless on BeOS _MSC_VER is defined. Beats me whether it is, but doubt it. The code in selectmodule when _MSC_VER is _not_ defined complains if a socket fd is = FD_SETSIZE _or_ is 0. But the new code in socketmodule on non-Windows boxes is happy with negative fds, saying fine whenever fd FD_SETSIZE. Is that right or wrong? The answer isn't so important to me as that this kind of crap always happens when platform-specific logic ends up getting defined in multiple modules. Much better to define macros to hide this junk, exactly once; pyport.h is the natural place for it. ___ 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] Baffled by PyArg_ParseTupleAndKeywords modification
Aahz wrote: That future version might get published in 2270, when everybody has switched to C++, and compatibility with C is no longer required. Just for the clarification of those of us who are not C/C++ programmers, are you saying that this is different from the meaning in Python, where deprecated means that something *IS* going away? To repeat the literal words from the standard: Annex D [depr]: 1 This clause describes features of the C++ Standard that are specified for compatibility with existing implementations. 2 These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Greg Ewing wrote: There are *already* differences which make C and C++ annoyingly incompatible. One is the const char * const * issue that appeared here. Of course there are differences. C++ has classes, C doesn't. C++ has function overloading, C doesn't. C++ has assignment from char** to const char*const*, C doesn't. Why is it annoying that C++ extends C? Another is that it no longer seems to be permissible to forward-declare static things, Not sure what you are referring to. You can forward-declare static functions in C++ just fine. when everybody has switched to C++, and compatibility with C is no longer required. Yeeks, I hope not! The world needs *less* C++, not more... I'm sure the committee waits until you retire before deciding that compatibility with C is not needed anymore :-) Sure you can still use stdio, and it is never going away (it isn't deprecated). However, you have to spell the header as #include cstdio and then refer to the functions as std::printf, std::stderr, etc. Which makes it a very different language from C in this area. That's my point. That future version of C++ to be published in 2270, yes, it will be different from C, because the last C programmer will have died 20 years ago. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to get the Python-2.4.2 sources from SVN?
Martin v. Löwis [EMAIL PROTECTED] writes: David Abrahams wrote: It isn't completely clear which branch or tag to get, and Google turned up no obvious documentation. http://svn.python.org/projects/python/tags/r242/ Thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.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] PEP 351
Hello, I just wanted to say this: you can reject PEP 351, please don't reject the idea of frozen objects completely. I'm working on an idea similar to that of the PEP, and I think that it can be done elegantly, without the concrete problems that Raymond pointed. I didn't work on it in the last few weeks, because of my job, but I hope to come back to it soon and post a PEP and a reference implementation in CPython. My quick responses, mostly to try to convince that I know a bit about what I'm talking about: First about the last point: I suggest that the function will be named frozen(x), which suggests that nothing happens to x, you only get a frozen x. I suggest that this operation won't be called freezing x, but making a frozen copy of x. Now, along with the original order. Frozen dicts - if you want, you can decide that dicts aren't frozenable, and that's ok. But if you do want to make frozen copies of dicts, it isn't really such a problem - it's similar to hashing a tuple, which requires recursive hashing of all its elements; for making a frozen copy of a dict, you make a frozen copy of all its values. Treating all containers polymorphically - I don't suggest that. In my suggestion, you may have frozen lists, frozen tuples (which are normal tuples with frozen elements), frozen sets and frozen dicts. Treating tuples as frozen lists - I don't suggest to do that. But if my suggestion is accepted, there would be no need for tuples - frozen lists would be just as useful. And about the other concerns: More important than all of the above is the thought that auto-freezing is like a bad C macro, it makes too much implicit and hides too much -- the supported methods change, there is a issue keeping in sync with the non-frozen original, etc. In my experience with frozensets, I've learned that freezing is not an incidental downstream effect; instead, it is an intentional, essential part of the design and needs to be explicit. I think these concerns can only be judged given a real suggestion, along with an implementation. I have already implemented most of my idea in CPython, and I think it's elegant and doesn't cause problems. Of course, I may not be objective about the subject, but I only ask to wait for the real suggestion before dropping it down. To summarize, I see the faults in PEP 351. I think that another, fairly similar idea might be a good one. Have a good week, Noam ___ 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] Pervasive socket failures on Windows
Tim Peters wrote: The code in selectmodule when _MSC_VER is _not_ defined complains if a socket fd is = FD_SETSIZE _or_ is 0. But the new code in socketmodule on non-Windows boxes is happy with negative fds, saying fine whenever fd FD_SETSIZE. Is that right or wrong? I think it is right: the code just knows that negative values cannot happen. The socket handles originate from system calls (socket(2), accept(2)), and a negative value returned there is an error. However, the system might (and did) return handles larger than FD_SETSIZE (as the kernel often won't know what value FD_SETSIZE has). The answer isn't so important to me as that this kind of crap always happens when platform-specific logic ends up getting defined in multiple modules. Much better to define macros to hide this junk, exactly once; pyport.h is the natural place for it. That must be done carefully, though. For example, how should the line max = 0; /* not used for Win32 */ be treated? Should we introduce a #define Py_SELECT_NUMBER_OF_FDS_PARAMETER_IS_IRRELEVANT? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 - Executing Modules as Scripts
Paul Moore wrote: On 2/11/06, Nick Coghlan [EMAIL PROTECTED] wrote: I finally finished updating PEP 338 to comply with the flexible importing system in PEP 302. The result is a not-yet-thoroughly-tested module that should allow the -m switch to execute any module written in Python that is accessible via an absolute import statement. Does this implementation resolve http://www.python.org/sf/1250389 as well? A reading of the PEP would seem to imply that it does, but the SF patches you mention don't include any changes to the core, so I'm not sure... I copied the module and test packages over to my Python 2.4 site packages, and running modules from inside zip packages does indeed work as intended (with an explicit redirection through runpy, naturally). Kudos to the PEP 302 folks - I only tested with runpy.py's Python emulation of PEP 302 style imports for the normal file system initially, but zipimport still worked correctly on the first go. For Python 2.5, this redirection from the command line switch to runpy.run_module should be automatic. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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 351
[Noam] I just wanted to say this: you can reject PEP 351, please don't reject the idea of frozen objects completely. I'm working on an idea similar to that of the PEP, . . . I think these concerns can only be judged given a real suggestion, along with an implementation. I have already implemented most of my idea in CPython, and I think it's elegant and doesn't cause problems. Of course, I may not be objective about the subject, but I only ask to wait for the real suggestion before dropping it down I was afraid of this -- the freezing concept is a poison that will cause some good minds to waste a good deal of their time. Once frozensets were introduced, it was like lighting a flame drawing moths to their doom. At first, it seems like such a natural, obvious extension to generically freeze anything that is mutable. People exploring it seem to lose sight of motivating use cases and get progressively turned around. It doesn't take long to suddenly start thinking it is a good idea to have mutable strings, to recursively freeze components of a dictionary, to introduce further list/tuple variants, etc. Perhaps a consistent solution can be found, but it no longer resembles Python; rather, it is a new language, one that is not grounded in real-world use cases. Worse, I think a frozen() built-in would be hazardous to users, drawing them away from better solutions to their problems. Expect writing and defending a PEP to consume a month of your life. Before devoting more of your valuable time, here's a checklist of questions to ask yourself (sort of a mid-project self-assessment and reality check): 1. It is already possible to turn many objects into key strings -- perhaps by marshaling, pickling, or making a custom repr such as repr(sorted(mydict.items())). Have you ever had occasion to use this? IOW, have you ever really needed to use a dictionary as a key to another dictionary? Has there been any clamor for a frozendict(), not as a toy recipe but as a real user need that cannot be met by other Python techniques? If the answer is no, it should be a hint that a generalized freezing protocol will rot in the basement. 2. Before introducing a generalized freezing protocol, wouldn't it make sense to write a third-party extension for just frozendicts, just to see if anyone can possibly make productive use of it? One clue would be to search for code that exercises the existing code in dict.__eq__(). If you rarely have occasion to compare dicts, then it is certainly even more rare to want to be able to hash them. If not, then is this project being pursued because it is interesting or because there's a burning need that hasn't surfaced before? 3. Does working out the idea entail recursive freezing of a dictionary? Does that impose limits on generality (you can freeze some dicts but not others)? Does working out the idea lead you to mutable strings? If so, don't count on Guido's support.. 4. Leaving reality behind (meaning actual problems that aren't readily solvable with the existing language), try to contrive some hypothetical use cases? Any there any that are not readily met by the simple recipe in the earlier email: http://mail.python.org/pipermail/python-dev/2005-October/057586.html ? 5. How extensively does the rest of Python have to change to support the new built-in. If the patch ends-up touching many objects and introducing new rules, then the payoff needs to be pretty darned good. I presume that for frozen(x) to work a lot of types have to be modified. Python seems to fare quite well without frozendicts and frozenlists, so do we need to introduce them just to make the new frozen() built-in work with more than just sets? Raymond ___ 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 351
On Sat, 11 Feb 2006 12:55:10 -0800, Alex Martelli [EMAIL PROTECTED] wrote:
On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
[Guido van Rossum]
PEP 351 - freeze protocol. I'm personally -1; I don't like the
idea of
freezing arbitrary mutable data structures. Are there champions who
want to argue this?
It has at least one anti-champion. I think it is a horrible idea
and would
like to see it rejected in a way that brings finality. If needed,
I can
elaborate in a separate thread.
Could you please do that? I'd like to understand all of your
objections. Thanks!
PMJI. I just read PEP 351, and had an idea for doing the same without
pre-instantiating protected
subclasses, and doing the wrapping on demand instead. Perhaps of interest? (Or
if already considered
and rejected, shouldn't this be mentioned in the PEP?)
The idea is to factor out freezing from the objects to be frozen. If it's going
to involve copying anyway,
feeding the object to a wrapping class constructor doesn't seem like much extra
overhead.
The examples in the PEP were very amenable to this approach, but I don't know
how it would apply
to whatever Alex's use cases might be.
Anyhow, why shouldn't you be able to call freeze(an_ordinary_list) and get back
freeze(xlist(an_ordinary_list))
automatically, based e.g. on a freeze_registry_dict[type(an_ordinary_list)] =
xlist lookup, if plain hash fails?
Common types that might be usefully freezable could be pre-registered, and when
a freeze fails
on a user object (presumably inheriting a __hash__ that bombs or because he
wants it to) the programmer's
solution would be to define a suitable callable to produce the frozen object,
and register that, but not modify his
unwrapped pre-freeze-mods object types and instantiations.
BTW, xlist wouldn't need to exist, since freeze_registry_dict[type(alist)]
could just return the tuple type.
Otherwise the programmer would make a wrapper class taking the object as an
__init__ (or maybe __new__) arg,
and intercepting the mutating methods etc., and stuff that in the
freeze_registry_dict. IWT some metaclass stuff
might make it possible to parameterize a lot of wrapper class aspects, e.g., if
you gave it a
__mutator_method_name_list__ to work with.
Perhaps freeze builtin could be a callable object with __call__ for the freeze
function call
and with e.g. freeze.register(objtype, wrapper_class) as a registry API.
I am +0 on any of this in any case, not having had a use case to date, but I
thought taking the
__freeze__ out of the objects (by not forcing them to be them
pre-instantiatated as wrapped instances)
and letting registered freeze wrappers do it on demand instead might be
interesting to someone.
If not, or if it's been discussed (no mention on the PEP tho) feel free to
ignore ;-)
BTW freeze as just described might be an instance of
class Freezer(object):
def __init__(self):
self._registry_dict = {
set:frozenset,
list:tuple,
dict:imdict}
def __call__(self, obj):
try: return hash(obj)
except TypeError:
freezer = self._registry_dict.get(type(obj))
if freezer: return freezer(obj)
raise TypeError('object is not freezable')
def register(self, objtype, wrapper):
self._registry_dict[objtype] = wrapper
(above refers to imdict from PEP 351)
Usage example:
import alt351
freeze = alt351.Freezer()
(well, pretend freeze is builtin)
fr5 = freeze(range(5))
fr5
(0, 1, 2, 3, 4)
d = dict(a=1,b=2)
d
{'a': 1, 'b': 2}
fd = freeze(d)
fd
{'a': 1, 'b': 2}
fd['a']
1
fd['a']=3
Traceback (most recent call last):
File stdin, line 1, in ?
File alt351.py, line 7, in _immutable
raise TypeError('object is immutable')
TypeError: object is immutable
type(fd)
class 'alt351.imdict'
+0 ;-)
Regards,
Bengt Richter
___
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] Pervasive socket failures on Windows
[Tim]
The code in selectmodule when _MSC_VER is _not_ defined complains if a
socket fd is = FD_SETSIZE _or_ is 0. But the new code in
socketmodule on non-Windows boxes is happy with negative fds, saying
fine whenever fd FD_SETSIZE. Is that right or wrong?
[Martin]
I think it is right: the code just knows that negative values
cannot happen. The socket handles originate from system calls
(socket(2), accept(2)), and a negative value returned there is
an error. However, the system might (and did) return handles
larger than FD_SETSIZE (as the kernel often won't know what
value FD_SETSIZE has).
Since the new code was just added, you can remember that now. No
comments record the reasoning, though, and over time it's likely to
become another mass of micro-optimized mystery code. If it's true
that negative values can't happen (and I believe that), then it
doesn't hurt to verify that they're = 0 either (except from a
micro-efficiency view), and it would simplify the code do to so.
The answer isn't so important to me as that this kind of crap always
happens when platform-specific logic ends up getting defined in
multiple modules. Much better to define macros to hide this junk,
exactly once; pyport.h is the natural place for it.
That must be done carefully, though. For example, how should
the line
max = 0; /* not used for Win32 */
be treated? Should we introduce a
#define Py_SELECT_NUMBER_OF_FDS_PARAMETER_IS_IRRELEVANT?
I wouldn't: I'd simply throw away the current confusing avoidance of
computing max on Windows. That's another case where
platform-specific micro-efficiency seems the only justification
(select() on Windows ignores its first argument; there's nothing
special about 0 here, despite that the code currently makes 0 _look_
special on Windows somehow).
So fine by me if the current:
#if defined(_MSC_VER)
max = 0; /* not used for Win32 */
#else /* !_MSC_VER */
if (v 0 || v = FD_SETSIZE) {
PyErr_SetString(PyExc_ValueError,
filedescriptor out of range in select());
goto finally;
}
if (v max)
max = v;
#endif /* _MSC_VER */
block got replaced by, e.g.,:
max = 0;
if (! Py_IS_SOCKET_FD_OK(v)) {
PyErr_SetString(PyExc_ValueError,
filedescriptor out of range in select());
goto finally;
}
if (v max)
max = v;
Unlike the current code, that would, for example, also allow for the
_possibility_ of checking that v != INVALID_SOCKET on Windows, by
fiddling the Windows expansion of Py_IS_SOCKET_FD_OK (and of course
all users of that macro would grow the same new smarts).
I'm not really a macro fan: I'm a fan of centralizing portability
hacks in config header files, and hiding them under abstractions. C
macros are usually strong enough to support this, and are all the
concession to micro-efficiency I'm eager ;-) to make.
___
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 338 - Executing Modules as Scripts
Paul Moore wrote: On 2/11/06, Nick Coghlan [EMAIL PROTECTED] wrote: I finally finished updating PEP 338 to comply with the flexible importing system in PEP 302. The result is a not-yet-thoroughly-tested module that should allow the -m switch to execute any module written in Python that is accessible via an absolute import statement. Does this implementation resolve http://www.python.org/sf/1250389 as well? A reading of the PEP would seem to imply that it does, but the SF patches you mention don't include any changes to the core, so I'm not sure... I've uploaded a patch with the necessary changes to main.c to the PEP 338 implementation tracker item. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Pervasive socket failures on Windows
On 2/11/06, Tim Peters [EMAIL PROTECTED] wrote: [Tim telling how I broke pyuthon] [Martin fixing it] Sorry for the breakage (I didn't know about the Windows issues). Thank you Martin for fixing it. I agree with the solution. I was away from mail, ahem, working. n ___ 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] release plan for 2.5 ?
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: alpha 1: May 2006 alpha 2: June 2006 beta 1: July 2006 beta 2: August 2006 rc 1:September 2006 final: September 2006 I think this is very reasonable. Based on Martin's message and if we can get everyone fired up and implementing, it would possible to start in April. I'll update the PEP for starting in May now. We can revise further later. ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. I think PyCon is too early, but 3 alphas is a good idea. I'll add this as well. Probably separated by 3-4 weeks so it doesn't change the schedule much. The exact schedule will still changed based on release manager availability and other stuff that needs to be implemented. PEP 353: Using ssize_t as the index type Neal tells me that this is in progress in a branch, but that the code is not yet flawless (tons of warnings etc.). Martin, can you tell us more? When do you expect this to land? Maybe aggressively merging into the HEAD and then releasing it as alpha would be a good way to shake out the final issues??? I'm tempted to say we should merge now. I know the branch works on 64-bit boxes. I can test on a 32-bit box if Martin hasn't already. There will be a lot of churn fixing problems, but maybe we can get more people involved. n ___ 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] release plan for 2.5 ?
On 2/10/06, Georg Brandl [EMAIL PROTECTED] wrote: I am not experienced in releasing, but with the multitude of new things introduced in Python 2.5, could it be a good idea to release an early alpha not long after all (most of?) the desired features are in the trunk? In the past, all new features had to be in before beta 1 IIRC (it could have been beta 2 though). The goal is to get things in sooner, preferably prior to alpha. For 2.5, we should strive really hard to get features implemented prior to alpha 1. Some of the changes (AST, ssize_t) are pervasive. AST while localized, ripped the guts out of something every script needs (more or less). ssize_t touches just about everything it seems. n ___ 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
