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
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. )
>
>
> Things like this are really starting to get on my groat.
> It
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 test
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)
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. Thi
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:
>
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
__
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. Thi
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
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 mechan
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,
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
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: inva
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 exampl
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.
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,
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 T
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 o
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/l
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
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.
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 li
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 d
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
[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 d
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
___
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 pla
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
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
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, a
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 Pytho
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 tr
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
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? Che
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 b
+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 inc
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 vari
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 i
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
> to begin with:
>
> PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject
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 arg
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,
- Original Message -
From: "Alex Martelli" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc:
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
[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 currentl
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, w
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 c
"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.co
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
Armin Rigo wrote:
> 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.
It appears to be language-defined. Looking at the assignment
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
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 Pytho
[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 im
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 c
[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
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 Pytho
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
_
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
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
57 matches
Mail list logo
