Re: [Python-Dev] release plan for 2.5 ?

[Neal Norwitz]

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

Re: [Python-Dev] release plan for 2.5 ?

[Neal Norwitz]

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] Pervasive socket failures on Windows

[Neal Norwitz]

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] PEP 338 - Executing Modules as Scripts

[Nick Coghlan]

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

[Tim Peters]

[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 351

[Bengt Richter]

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 "", line 1, in ?
   File "alt351.py", line 7, in _immutable
 raise TypeError('object is immutable')
 TypeError: object is immutable
 >>> type(fd)
 

+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] PEP 351

[Raymond Hettinger]

[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 338 - Executing Modules as Scripts

[Nick Coghlan]

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] Pervasive socket failures on Windows

[Martin v. Löwis]

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] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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

  char **a;
  const char* const* b;
  b = a;

then, in C++, 4.4p4 [conv.qual] has a rather longish formula to
decide that the assignment is well-formed. In essence, it goes
like this:
- the pointers are "similar": they have the same levels of indirection,
  and the same underlying type.
- In all places where the type of a has const/volatile qualification,
  the type of b also has these qualifications (i.e. none in the
  example)
- Starting from the first point where the qualifications differ
  (from left to right), all later levels also have const.

I'm unsure about C; I think the rule comes from 6.3.2.3p2:

   [#2]  For  any  qualifier  q, a pointer to a non-q-qualified
   type may be  converted  to  a  pointer  to  the  q-qualified
   version  of  the type; the values stored in the original and
   converted pointers shall compare equal.

So it is possible to convert a non-const pointer to a const pointer,
but only if the the target types are the same. In the example, they
are not: the target type of a is char*, the target of b is
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] PEP 351

[Noam Raphael]

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] How to get the Python-2.4.2 sources from SVN?

[David Abrahams]

"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] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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 
>>
>>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] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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] Pervasive socket failures on Windows

[Tim Peters]

[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] PEP 351

[Raymond Hettinger]

- 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 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] Baffled by PyArg_ParseTupleAndKeywords modification

[Greg Ewing]

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 
> 
> 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

[Barry Warsaw]

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

[Armin Rigo]

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 *,
>   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

[Python-Dev] PEP 351

[Alex Martelli]

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] How to get the Python-2.4.2 sources from SVN?

[David Abrahams]

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

Re: [Python-Dev] The decorator(s) module

[Crutcher Dunnavant]

+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 .
>
> 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] Where to put "post-it notes"?

[Georg Brandl]

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] Where to put "post-it notes"?

[Nick Coghlan]

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] PEP 338 - Executing Modules as Scripts

[Nick Coghlan]

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 ". 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] Baffled by PyArg_ParseTupleAndKeywords modification

[Bengt Richter]

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/pydev>gcc 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/pydev>g++ martin.c
martin.c: In function `int main()':
martin.c:19: invalid conversion from `char**' to `const char**'

[07:17] /c/pywk/pydev>gcc -v

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]

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 ". 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] file.next() vs. file.readline()

[Thomas Wouters]

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]

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] Baffled by PyArg_ParseTupleAndKeywords modification

[Aahz]

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] To know how to set "pythonpath"

[Aahz]

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

[Python-Dev] Where to put "post-it notes"?

[Georg Brandl]

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] How to get the Python-2.4.2 sources from SVN?

[Martin v. Löwis]

[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

Re: [Python-Dev] How to get the Python-2.4.2 sources from SVN?

[Thomas Wouters]

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] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

[Mark Russell]

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

[Python-Dev] To know how to set "pythonpath"

[M, Raveendra Babu (STSD)]

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] How to get the Python-2.4.2 sources from SVN?

[skip]

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

Re: [Python-Dev] How to get the Python-2.4.2 sources from SVN?

[Martin v. Löwis]

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

[Python-Dev] How to get the Python-2.4.2 sources from SVN?

[David Abrahams]

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] PEP 338 - Executing Modules as Scripts

[Nick Coghlan]

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

Re: [Python-Dev] Pervasive socket failures on Windows

[Martin v. Löwis]

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] Let's just *keep* lambda

[Keith Dart]

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
   
   =


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]

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] The decorator(s) module

[Duncan Booth]

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] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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] Baffled by PyArg_ParseTupleAndKeywords modification

[Bengt Richter]

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 
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\pydev>cl 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\pydev>cl 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\pydev>martin
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] The decorator(s) module

[Thomas Wouters]

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] release plan for 2.5 ?

[Nick Coghlan]

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

[Python-Dev] PEP 338 - Executing Modules as Scripts

[Nick Coghlan]

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

[Python-Dev] The decorator(s) module

[Georg Brandl]

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 .

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 ?

[Georg Brandl]

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

Re: [Python-Dev] release plan for 2.5 ?

[Georg Brandl]

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

[Python-Dev] The decorator(s) module

[Georg Brandl]

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 .

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] _length_cue()

[Bengt Richter]

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

Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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 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 

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

[Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]

[Bengt Richter]

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 u"b'...'" just before
being turned into bytes.

Should that then be an internal straight u"b'...'".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