Re: [Python-Dev] Let's just *keep* lambda

[Valentino Volonghi aka Dialtone]

On Fri, 10 Feb 2006 16:49:13 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Valentino Volonghi aka Dialtone wrote:
>
>> when some_operation_that_results_in_a_deferred() -> result:
>> if result == 'Initial Value':
>> when work_on_result_and_return_a_deferred(result) -> inner_res:
>> print inner_res
>> else:
>> print "No work on result"
>> reactor.stop()
>
>Hmmm. This looks remarkably similar to something I got half
>way through dreaming up a while back, that I was going to
>call "Simple Continuations" (by analogy with "Simple Generators").
>Maybe I should finish working out the details and write it up.
>
>On the other hand, it may turn out that it's subsumed by
>the new enhanced generators plus a trampoline.

This in only partially true. In fact, let's consider again twisted for the 
example, you can do something like this:

@defgen
def foo():
for url in urls:
page = yield client.getPage(url)
print page

This has 2 disadvantages IMHO. First of all I have to use a function or a 
method decorated with @defgen to write that. But most important that code, 
although correct is serializing things that could be parallel. The solution is 
again simple but not really intuitive:

@defgen
def foo():
for d in map(client.getPage, urls):
page = yield d
print page

Written in this way it will actually work in a parallel way but it is not 
really an intuitive solution.

Using when instead:

for url in urls:
when client.getPage(url) -> page:
print page

This wouldn't have any problem and is quite readable. A similar construct is 
used in the E language and here 
http://www.skyhunter.com/marcs/ewalnut.html#SEC20 is explained how when works 
for them and their promise object. You can also have multiple things to wait 
for:

when (client.getPage(url), cursor.execute(query)) -> (page, results):
print page, results

or

l = [list, of, deferreds]

when l -> *results:
print results

and we could catch errors in the following way:

when client.getPage(url) -> page:
print page
except socket.error, e:
print "something bad happened"

HTH

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
New Pet: http://www.stiq.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] Linking with mscvrt

[Giovanni Bajo]

Martin v. Löwis wrote:

>>> At first glance, this is a minor issue - passing FILE* pointers
>>> across
>>> DLL boundaries isn't something I'd normally expect people to do -
>>> but
>>> look further and you find you're opening a real can of worms. For
>>> example, Python has public APIs which take FILE* parameters.
>>
>>
>>So convert them to taking PyWrappedFile * parameters.
>
> Easy to say, hard to do.

But *that's* the solution for this problem. It's always been like this under
Windows and will always be. Changing back to msvcrt so that people must compile
their extension with non-standard compilation options it's really *worse* than
just requiring msvcrt71 and punt. There's also a free compiler from Microsoft
and tons of webpages which say how to compile with it. Or with mingw, even.

So, I really believe that the situation is settling down. People are doing what
they want to, with some difficulties perhaps, but there's nothing really
undoable. If another change has to be pursued, it is to abstract Python from
CRT altogether, or at least across boundaries.
-- 
Giovanni Bajo

___
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

[Raymond Hettinger]

Die thread, die!
___
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()

[Raymond Hettinger]

[Giovanni]
>> I was really attracted to the idea of having more informative iterator
>> representations but learned that even when it could be done, it wasn't
>> especially useful.  When someone creates an iterator at the
>> interactive
>> prompt, they almost always either wrap it in a consumer function or
>> they
>> assign it to a variable.  The case of typing just,
>> "enumerate([1,2,3])",
>> comes up only once, when first learning was enumerate() does.
>
> On the other hand, it's very common to see the iterator in the debug 
> window
> showing the locals or the watches. And it's pretty easy to add some 
> debugging
> print statement to the code, run the program/test, find out that, hey, 
> that
> function returns an iterator, go back and add a list() around it to find 
> out
> what's inside.
>
> I would welcome if the iterator repr string could show, when possible, the 
> next
> couple of elements.

Sorry, that's a pipe-dream.  Real use-cases for enumerate() don't usually 
have the luxury of having an argument that is a sequence.  Instead, you have 
to run the iteration a few steps to see what lies ahead.  In general, this 
isn't always possible (stdin for example) or desirable (where the iterator 
is time consuming or memory intensive and so shouldn't be run unless the 
value is actually needed) or may even be a disaster (if the iterator 
participates in co-routine style code that expects to be passing control 
back and forth between multiple open iterators).  IOW, you cannot safely run 
an iterator a few steps in advance, save-up the results for display, and 
then expect everything else to work right.

I spent a good time of time pursuing this mirage, but there was no water:
http://mail.python.org/pipermail/python-dev/2004-April/044136.html

AFAICT, the only way to achieve the effect you want is to get an environment 
where all iterators are designed around an API that supports being run 
forward and backward (such as the one demonstrated by Armin at PyCon last 
year).


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

[Thomas Wouters]

On Fri, Feb 10, 2006 at 12:36:09AM -0500, Tim Peters wrote:
> [Tim]
> > ...  FD_SETSIZE is the maximum number of distinct fd's an fdset can
> > hold, and the numerical magnitude of any specific fd has nothing to do
> > with that in general (they may be related in fact on Unix systems that
> > implement an fdset as "a big bit vector" -- but Windows doesn't work
> > that way, and neither do all Unix systems, and nothing in socket
> > specs requires an implementation to work that way).

> Hmm.  Looks like POSIX _does_ require that.  Can't work on Windows,
> though.  I have a distinct memory of a 64-bit Unix that didn't work
> that way either, but while that memory is younger than I am, it's too
> old for me to recall more than just that ;-).

Perhaps the memory you have is of select-lookalikes, like poll(), or maybe
of vendor-specific (and POSIX-breaking) extensions to select(). select()
performs pretty poorly on large fdsets with holes in, and has the fixed size
fdset problem, so poll() was added to fix that (by Linux and later by XPG4,
IIRC.) poll() takes an array of structs containing the fd, the operations to
watch for and an output parameter with seen events. Does that jar your
memory? :)

(The socketmodule has support for poll(), on systems that have it, by the
way.)

-- 
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] cProfile module

[Nick Coghlan]

Armin Rigo wrote:
> Hi all,
> 
> As promized two months ago, I eventually finished the integration of the
> 'lsprof' profiler.  It's now in an internal '_lsprof' module that is
> exposed via a 'cProfile' module with the same interface as 'profile',
> producing compatible dump stats that can be inspected with 'pstats'.

Hurrah! (trying to optimise the Decimal module before 2.4 was a painful 
exercise, because hotshot wasn't really up to the job and executing the tests 
and the benchmark under the normal profile module was horribly slow. . .).

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

[Nick Coghlan]

Guido van Rossum wrote:
>> But, then it *should* be renamed to i.e. "__true_int__".  One such place
>> is in abstract.c sequence_repeat function.
> 
> I don't like __true_int__ very much. Personally, I'm fine with calling
> it __index__ after the most common operation. (Well, I would be since
> I think I came up with the name in the first place. :-) Since naming
> is always so subjective *and* important, I'll wait a few days, but if
> nobody suggests something better then we should just go with
> __index__.

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. Numbers conceptually 
representing continuously variable quantities (such as floats and decimals) 
are the ones that really shouldn't define this method.

I wouldn't mind __index__ though, as even though some of the use cases won't 
be strictly using the result as an index, the shared characteristic of being 
isomorphic to the integers should be sufficient to allow the term to make some 
sort of sense.

This would hardly be the first case where names of operators are overloaded 
using imprecise terminology, after all. 'or', 'and', 'sub' and 'xor' aren't 
the right terms for set union, intersection, difference and disjunction, but 
they're close enough conceptually that the names still have meaning. Ditto for 
'mul' and 'add' meaning repetition and concatenation for sequences (no comment 
on 'mod' and string formatting though. . .)

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

[Nick Coghlan]

Adam Olsen wrote:
> I guess my confusion revolves around float to Decimal.  Is lossless
> conversion a good thing in python, or is prohibiting float to Decimal
> conversion just a fudge to prevent people from initializing a Decimal
> from a float when they really want a str?

The general rule is that a lossy conversion is fine, so long as the programmer 
explicitly requests it.

float to Decimal is a special case, which has more to do with the nature of 
Decimal and the guarantees it provides, than to do with general issues of 
lossless conversion.

Specifically, what does Decimal(1.1) mean? Did you want Decimal("1.1") or 
Decimal("1.10001")? Allowing direct conversion from float would simply 
infect the Decimal type with all of the problems of binary floating point 
representations, without providing any countervailing benefit.

The idea of providing a special notation or separate method for float 
precision was toyed with, but eventually rejected in favour of the existing 
string formatting notation and a straight up type error. Facundo included the 
gory details in the final version of his PEP [1].

Cheers,
Nick.


[1] http://www.python.org/peps/pep-0327.html#from-float

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

[Nick Coghlan]

Armin Rigo wrote:
> Indeed, I don't foresee any place where it would help apart from the
> __repr__ of the iterators, which is precisely what I'm aiming at.  The
> alternative here would be a kind of "smart" global function that knows
> about many built-in iterator types and is able to fish for the data
> inside automatically (but this hits problems of data structures being
> private).  I thought that __getitem_cue__ would be a less dirty
> solution.  I really think a better __repr__ would be generally helpful,
> and I cannot think of a 3rd solution at the moment...  (Ideas welcome!)

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)

If the subiterators themselves have decent repr methods, the top-level repr 
should also look reasonable.

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

[Armin Rigo]

Hi Greg,

On Thu, Feb 09, 2006 at 04:27:54PM +1300, Greg Ewing wrote:
> The iterator protocol is currently very simple and
> well-focused on a single task -- producing things
> one at a time, in sequence. Let's not clutter it up
> with too much more cruft.

Please refer to my original message: I intended these methods to be
private and undocumented, not part of any official protocol in any way.


A bientot,

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

Re: [Python-Dev] _length_cue()

[Armin Rigo]

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.


A bientot,

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

Re: [Python-Dev] _length_cue()

[Armin Rigo]

Hi Raymond,

On Wed, Feb 08, 2006 at 09:21:02PM -0500, Raymond Hettinger wrote:
> (... __getitem_cue__ ...)
> Before putting this in production, it would probably be worthwhile to search 
> for code where it would have been helpful.  In the case of __length_cue__, 
> there was an immediate payoff.

Indeed, I don't foresee any place where it would help apart from the
__repr__ of the iterators, which is precisely what I'm aiming at.  The
alternative here would be a kind of "smart" global function that knows
about many built-in iterator types and is able to fish for the data
inside automatically (but this hits problems of data structures being
private).  I thought that __getitem_cue__ would be a less dirty
solution.  I really think a better __repr__ would be generally helpful,
and I cannot think of a 3rd solution at the moment...  (Ideas welcome!)


A bientot,

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

Re: [Python-Dev] _length_cue()

[Nick Coghlan]

Armin Rigo 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.

Ah, I see the use case now. You're right in thinking I was mainly considering 
the debugging element (and supporting even that would be an improvement on the 
current repr methods, which are just the 'type with instance ID' default repr).

In terms of "what does it do" though, I'd tend to actually iterate the thing:

Py> for x in enumerate("spam"): print x
...
(0, 's')
(1, 'p')
(2, 'a')
(3, 'm')

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] Post-PyCon PyPy Sprint: February 27th - March 2nd 2006

[Michael Hudson]

The next PyPy sprint is scheduled to take place right after 
PyCon 2006 in Dallas, Texas, USA. 

We hope to see lots of newcomers at this sprint, so we'll give
friendly introductions.  Note that during the Pycon conference 
we are giving PyPy talks which serve well as preparation.  

Goals and topics of the sprint 
--

While attendees of the sprint are of course welcome to work on what
they wish, we offer these ideas:

  - Work on an 'rctypes' module aiming at letting us use a ctypes
implementation of an extension module from the compiled pypy-c.

  - Writing ctypes implementations of modules to be used by the above
tool. 

  - Experimenting with different garbage collection strategies.

  - Implementing Python 2.5 features in PyPy

  - Implementation of constraints solvers and integration of dataflow
variables to PyPy.

  - Implement new features and improve the 'py' lib and py.test 
which are heavily used by PyPy (doctests/test selection/...).

  - Generally experiment with PyPy -- for example, play with
transparent distribution of objects or coroutines and stackless
features at application level.

  - Have fun!

Location


The sprint will be held wherever the PyCon sprints end up being held,
which is to say somewhere within the Dallas/Addison Marriott Quorum
hotel.

For more information see the PyCon 06 sprint pages:

  - http://us.pycon.org/TX2006/Sprinting
  - http://wiki.python.org/moin/PyCon2006/Sprints

Exact times 
---

The PyPy sprint will from from Monday February 27th until Thursday
March 2nd 2006. Hours will be from 10:00 until people have had enough.

Registration, etc.
-- 

If you know before the conference that you definitely want to attend
our sprint, please subscribe to the `PyPy sprint mailing list`_,
introduce yourself and post a note that you want to come.  Feel free
to ask any questions or make suggestions there!

There is a separate `PyCon 06 people`_ page tracking who is already
planning to come.  If you have commit rights on codespeak then you can
modify yourself a checkout of

  http://codespeak.net/svn/pypy/extradoc/sprintinfo/pycon06/people.txt

.. _`PyPy sprint mailing list`: 
http://codespeak.net/mailman/listinfo/pypy-sprint
.. _`PyCon 06 people`: 
http://codespeak.net/pypy/extradoc/sprintinfo/pycon06/people.txt

-- 
42. You can measure a programmer's perspective by noting his
attitude on the continuing vitality of FORTRAN.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
___
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] Baffled by PyArg_ParseTupleAndKeywords modification

[Jack Jansen]

I keep running into problems with the "const" modifications to  
PyArg_ParseTupleAndKeywords() (rev. 41638 by Jeremy).

I have lots of code of the form
char *kw[] = {"itself", 0};

if (PyArg_ParseTupleAndKeywords(_args, _kwds, "O&", kw,  
CFTypeRefObj_Convert, &itself)) ...
which now no longer compiles, neither with C nor with C++ (gcc4, both  
MacOSX and Linux). Changing the kw declaration to "const char *kw[]"  
makes it compile again.

I don't understand why it doesn't compile: even though the  
PyArg_ParseTupleAndKeywords signature promises that it won't change  
the "kw" argument I see no reason why I shouldn't be able to pass a  
non-const argument.

And to make matters worse adding the "const" of course makes the code  
non-portable to previous versions of Python (where the C compiler  
rightly complains that I'm passing a const object through a non-const  
parameter).

Can anyone enlighten me?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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

[Guido van Rossum]

OMG. Are we now adding 'const' modifiers to random places? I thought
"const propagation hell" was a place we were happily avoiding by not
falling for that meme. What changed?

--Guido

On 2/10/06, Jack Jansen <[EMAIL PROTECTED]> wrote:
> I keep running into problems with the "const" modifications to
> PyArg_ParseTupleAndKeywords() (rev. 41638 by Jeremy).
>
> I have lots of code of the form
> char *kw[] = {"itself", 0};
>
> if (PyArg_ParseTupleAndKeywords(_args, _kwds, "O&", kw,
> CFTypeRefObj_Convert, &itself)) ...
> which now no longer compiles, neither with C nor with C++ (gcc4, both
> MacOSX and Linux). Changing the kw declaration to "const char *kw[]"
> makes it compile again.
>
> I don't understand why it doesn't compile: even though the
> PyArg_ParseTupleAndKeywords signature promises that it won't change
> the "kw" argument I see no reason why I shouldn't be able to pass a
> non-const argument.
>
> And to make matters worse adding the "const" of course makes the code
> non-portable to previous versions of Python (where the C compiler
> rightly complains that I'm passing a const object through a non-const
> parameter).
>
> Can anyone enlighten me?
> --
> Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma
> Goldman
>
>
> ___
> 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/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Jeremy Hylton]

On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> OMG. Are we now adding 'const' modifiers to random places? I thought
> "const propagation hell" was a place we were happily avoiding by not
> falling for that meme. What changed?

I added some const to several API functions that take char* but
typically called by passing string literals.  In C++, a string literal
is a const char* so you need to add a const_cast<> to every call site,
which is incredibly cumbersome.  After some discussion on python-dev,
I made changes to a small set of API functions and chased the
const-ness the rest of the way, as you would expect.  There was
nothing random about the places const was added.

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.

Jeremy


>
> --Guido
>
> On 2/10/06, Jack Jansen <[EMAIL PROTECTED]> wrote:
> > I keep running into problems with the "const" modifications to
> > PyArg_ParseTupleAndKeywords() (rev. 41638 by Jeremy).
> >
> > I have lots of code of the form
> > char *kw[] = {"itself", 0};
> >
> > if (PyArg_ParseTupleAndKeywords(_args, _kwds, "O&", kw,
> > CFTypeRefObj_Convert, &itself)) ...
> > which now no longer compiles, neither with C nor with C++ (gcc4, both
> > MacOSX and Linux). Changing the kw declaration to "const char *kw[]"
> > makes it compile again.
> >
> > I don't understand why it doesn't compile: even though the
> > PyArg_ParseTupleAndKeywords signature promises that it won't change
> > the "kw" argument I see no reason why I shouldn't be able to pass a
> > non-const argument.
> >
> > And to make matters worse adding the "const" of course makes the code
> > non-portable to previous versions of Python (where the C compiler
> > rightly complains that I'm passing a const object through a non-const
> > parameter).
> >
> > Can anyone enlighten me?
> > --
> > Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
> > If I can't dance I don't want to be part of your revolution -- Emma
> > Goldman
> >
> >
> > ___
> > 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/guido%40python.org
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> 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/jeremy%40alum.mit.edu
>
___
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]

Guido van Rossum wrote the following on 2006-02-09 at 16:27 PST:
===
> Since you probably won't stop until I give you an answer: I'm really
> not interested in a syntactic solution that allows multi-line lambdas.
===

Fuzzy little lambdas, wouldn't hurt a fly.
Object of much derision, one has to wonder why?

Docile little lambdas, so innocent and pure
Only wants to function with finality and closure.

Cute little lambdas, they really are so sweet
When ingested by a Python they make a tasty treat.

-- 

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

[Thomas Wouters]

On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote:
> On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > OMG. Are we now adding 'const' modifiers to random places? I thought
> > "const propagation hell" was a place we were happily avoiding by not
> > falling for that meme. What changed?
> 
> I added some const to several API functions that take char* but
> typically called by passing string literals.  In C++, a string literal
> is a const char* so you need to add a const_cast<> to every call site,
> which is incredibly cumbersome.  After some discussion on python-dev,
> I made changes to a small set of API functions and chased the
> const-ness the rest of the way, as you would expect.  There was
> nothing random about the places const was added.
> 
> 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.

Well, it's counter-intuitive, but a direct result of how pointer equivalence
is defined in C. I'm rusty in this part, so I will get some terminology
wrong, but IIRC, a variable A is of an equivalent type of variable B if they
hold the same type of data. So, a 'const char *' is equivalent to a 'char *'
because they both hold the memory of a 'char'. But a 'const char**' (or
'const *char[]') is not equivalent to a 'char **' (or 'char *[]') because
the first holds the address of a 'const char *', and the second the address
of a 'char *'. A 'char * const *' is equivalent to a 'char **' though.

As I said, I got some of the terminology wrong, but the end result is
exactly that: a 'const char **' is not equivalent to a 'char **', even
though a 'const char *' is equivalent to a 'char *'. Equivalence, in this
case, means 'can be automatically downcasted'. Peter v/d Linden explains
this quite well in "Expert C Programming" (aka 'Deep C Secrets'), but
unfortunately I'm working from home and I left my copy at a coworkers' desk.

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification

[Martin v. Löwis]

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.

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

[Jeremy Hylton]

It looks like a solution may be to define it as "const char * const *"
rather than "const char **".  I'll see if that works.

Jeremy

On 2/10/06, "Martin v. Löwis" <[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.
>
> 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]

Jeremy Hylton wrote:
> I added some const to several API functions that take char* but
> typically called by passing string literals.  In C++, a string literal
> is a const char* so you need to add a const_cast<> to every call site,

That's not true.

A string literal of length N is of type const char[N+1]. However,
a (deprecated) conversion of string literals to char* is provided
in the language. So assigning a string literal to char* or passing
it in a char* parameter is compliant with standard C++, no
const_cast is required.

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

[Jeremy Hylton]

On 2/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > I added some const to several API functions that take char* but
> > typically called by passing string literals.  In C++, a string literal
> > is a const char* so you need to add a const_cast<> to every call site,
>
> That's not true.
>
> A string literal of length N is of type const char[N+1]. However,
> a (deprecated) conversion of string literals to char* is provided
> in the language. So assigning a string literal to char* or passing
> it in a char* parameter is compliant with standard C++, no
> const_cast is required.

Ok.  I reviewed the original problem and you're right, the problem was
not that it failed outright but that it produced a warning about the
deprecated conversion:
warning: deprecated conversion from string constant to 'char*''

I work at a place that takes the same attitude as python-dev about
warnings:  They're treated as errors and you can't check in code that
the compiler generates warnings for.

Nonetheless, the consensus on the c++ sig and python-dev at the time
was to fix Python.  If we don't allow warnings in our compilations, we
shouldn't require our users at accept warnings in theirs.

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

[Tim Peters]

[Jeremy Hylton]
> ...
> 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.

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 *, ...);

That is, declare the keywords argument as a pointer to const pointer
to const char, rather than the current pointer to pointer to const
char.

How about someone on a Linux box try that with gcc, and check it in if
it solves Jack's problem (meaning that gcc stops whining about the
original spelling of his original example).
___
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

[Jeremy Hylton]

On 2/10/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> It looks like a solution may be to define it as "const char * const *"
> rather than "const char **".  I'll see if that works.

No.  It doesn't work.  I'm not sure about this one either, but some
searching suggests that you can pass a char** to a function taking
const char* const* in C++ but not in C.  Sigh.  I don't see any way to
avoid a warning in Jack's case.

Jeremy

>
> Jeremy
>
> On 2/10/06, "Martin v. Löwis" <[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.
> >
> > 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

[Tim Peters]

[Jeremy]
>> It looks like a solution may be to define it as "const char * const *"
>> rather than "const char **".  I'll see if that works.

[Jeremy]
> No.  It doesn't work.  I'm not sure about this one either, but some
> searching suggests that you can pass a char** to a function taking
> const char* const* in C++ but not in C.

Oops!  I think that's right.

> Sigh.  I don't see any way to avoid a warning in Jack's case.

Martin's turn ;-)
___
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

[Guido van Rossum]

On 2/10/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> I added some const to several API functions that take char* but
> typically called by passing string literals.  In C++, a string literal
> is a const char* so you need to add a const_cast<> to every call site,
> which is incredibly cumbersome.  After some discussion on python-dev,
> I made changes to a small set of API functions and chased the
> const-ness the rest of the way, as you would expect.  There was
> nothing random about the places const was added.

I still don't understand *why* this was done, nor how the set of
functions was chosen if not randomly.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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]

[Thomas Wouters]
> Perhaps the memory you have is of select-lookalikes, like poll(),

No, it was definitely select(), and on a 64-bit Unix (probably _not_
Linux) that allowed for an enormous number of sockets.

> or maybe of vendor-specific (and POSIX-breaking) extensions to select().

Yes, it must have been non-POSIX.

> select() performs pretty poorly on large fdsets with holes in, and has the 
> fixed
> size fdset problem, so poll() was added to fix that (by Linux and later by 
> XPG4,
> IIRC.) poll() takes an array of structs containing the fd, the operations to
> watch for and an output parameter with seen events. Does that jar your
> memory? :)

No more than it had been jarred ;-)  Well, a bit more:  it was
possible to pass a first argument to select() that was larger than
FD_SETSIZE.  In effect, FD_SETSIZE had no meaning.

> (The socketmodule has support for poll(), on systems that have it, by the
> way.)

Yup.
___
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

[Tim Peters]

[Jeremy]
>> I added some const to several API functions that take char* but
>> typically called by passing string literals.  In C++, a string literal
>> is a const char* so you need to add a const_cast<> to every call site,
>> which is incredibly cumbersome.  After some discussion on python-dev,
>> I made changes to a small set of API functions and chased the
>> const-ness the rest of the way, as you would expect.  There was
>> nothing random about the places const was added.

[Guido]
> I still don't understand *why* this was done,

Primarily to make life easier for C++ programmers using Python's C
API.  But didn't Jeremy just say that?

Some people (including me) have been adding const to char* API
arguments for years, but in much slower motion, and at least I did it
only when someone complained about a specific function.

> nor how the set of functions was chosen if not randomly.

[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.

If he had _stuck_ to that, we wouldn't be having this discussion :-) 
(that is, nobody passes string literals to
PyArg_ParseTupleAndKeywords's kws argument).
___
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

[Jeremy Hylton]

On 2/10/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Jeremy]
> I added some const to several API functions that take char* but
> typically called by passing string literals.
>
> If he had _stuck_ to that, we wouldn't be having this discussion :-)
> (that is, nobody passes string literals to
> PyArg_ParseTupleAndKeywords's kws argument).

They are passing arrays of string literals.  In my mind, that was a
nearly equivalent use case.  I believe the C++ compiler complains
about passing an array of string literals to char**.

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

[Guido van Rossum]

On 2/10/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Jeremy]
> >> I added some const to several API functions that take char* but
> >> typically called by passing string literals.  In C++, a string literal
> >> is a const char* so you need to add a const_cast<> to every call site,
> >> which is incredibly cumbersome.  After some discussion on python-dev,
> >> I made changes to a small set of API functions and chased the
> >> const-ness the rest of the way, as you would expect.  There was
> >> nothing random about the places const was added.
>
> [Guido]
> > I still don't understand *why* this was done,
>
> Primarily to make life easier for C++ programmers using Python's C
> API.  But didn't Jeremy just say that?

I didn't connect the dots.

> Some people (including me) have been adding const to char* API
> arguments for years, but in much slower motion, and at least I did it
> only when someone complained about a specific function.
>
> > nor how the set of functions was chosen if not randomly.
>
> [Jeremy]
> I added some const to several API functions that take char* but
> typically called by passing string literals.
>
> If he had _stuck_ to that, we wouldn't be having this discussion :-)
> (that is, nobody passes string literals to
> PyArg_ParseTupleAndKeywords's kws argument).

Is it too late to revert this one?

Is there another way to make C++ programmers happy (e.g. my having a
macro that expands to const when compiled with C++ but vanishes when
compiled with C?)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Tim Peters]

[Jeremy]
>>> I added some const to several API functions that take char* but
>>> typically called by passing string literals.

[Tim]
>> If he had _stuck_ to that, we wouldn't be having this discussion :-)
>> (that is, nobody passes string literals to
>> PyArg_ParseTupleAndKeywords's kws argument).

[Jeremy]
> They are passing arrays of string literals.  In my mind, that was a
> nearly equivalent use case.  I believe the C++ compiler complains
> about passing an array of string literals to char**.

It's the consequences:  nobody complains about tacking "const" on to a
former honest-to-God "char *" argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers.  For example, nobody could sanely object (and
nobody did :-)) to adding const to the attribute-name argument in
PyObject_SetAttrString().  Sticking to that creates no new problems
for anyone, so that's as far as I ever went.
___
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

[Jeremy Hylton]

On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/10/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > [Jeremy]
> > I added some const to several API functions that take char* but
> > typically called by passing string literals.
> >
> > If he had _stuck_ to that, we wouldn't be having this discussion :-)
> > (that is, nobody passes string literals to
> > PyArg_ParseTupleAndKeywords's kws argument).
>
> Is it too late to revert this one?

The change is still beneficial to C++ programmers, so my initial
preference is to keep it.  There are still some benefits to the other
changes, so it's isn't a complete loss if we revert it.

> Is there another way to make C++ programmers happy (e.g. my having a
> macro that expands to const when compiled with C++ but vanishes when
> compiled with C?)

Sounds icky.  Are we pretty sure there is no way to do the right thing
in plain C?  That is, declare the argument as taking a set of const
strings and still allow non-const strings to be passed without
warning.

Jeremy
___
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]

Jeremy Hylton wrote:
> Ok.  I reviewed the original problem and you're right, the problem was
> not that it failed outright but that it produced a warning about the
> deprecated conversion:
> warning: deprecated conversion from string constant to 'char*''
> 
> I work at a place that takes the same attitude as python-dev about
> warnings:  They're treated as errors and you can't check in code that
> the compiler generates warnings for.

In that specific case, I think the compiler's warning should be turned
off; it is a bug in the compiler if that specific warning cannot be
turned off separately.

While it is true that the conversion is deprecated, the C++ standard
defines this as

"Normative for the current edition of the Standard, but not guaranteed
to be part of the Standard in future revisions."

The current version is from 1998. I haven't been following closely,
but I believe there are no plans to actually remove the feature
in the next revision.

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

Don't you get a warning when including Python.h, because that
include ?

> Nonetheless, the consensus on the c++ sig and python-dev at the time
> was to fix Python.  If we don't allow warnings in our compilations, we
> shouldn't require our users at accept warnings in theirs.

We don't allow warnings for "major compilers". This specific compiler
appears flawed (or your configuration of it).

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]

Tim Peters wrote:
>>Sigh.  I don't see any way to avoid a warning in Jack's case.
> 
> 
> Martin's turn ;-)

I see two options:

1. Revert the change for the const char** keywords argument (but
   leave the change for everything else). C++ users should only
   see a problem if they have a const char* variable, not if
   they use literals (Jeremy's compiler's warning is insensate)

   For keyword arguments, people typically don't have char*
   variables; instead, they have an array of string literals.

2. Only add the const in C++:

#ifdef __cplusplus
#define Py_cxxconst const
#else
#define Py_cxxconst
#endif

   PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *,
   const char *, Py_cxxconst char *Py_cxxconst*, ...);


   This might look like it could break C/C++ interoperability on
   platforms that take an inventive interpretation of standard
   (e.g. if they would mangle even C symbols). However, I believe
   it won't make things worse: The C++ standard doesn't guarantee
   interoperability of C and C++ implementations at all, and the
   platforms I'm aware of support the above construct (since
   PA_PTAK is extern "C").

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

Re: [Python-Dev] _length_cue()

[Raymond Hettinger]

[Armin]
> 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

I prefer that the repr() of count() be left alone.  It follows the style 
used by xrange() and other repr's that can be run through eval(). Also, the 
existing repr keeps its information up-to-date to reflect the current state 
of the iterator:

>>> it = count(10)
>>> it.next()
10
>>> it
count(11)

A good deal of thought and discussion went into these repr forms.  See the 
python-dev discussions in April 2004.  Please don't randomly go in and 
change those choices.

For most of the tools like enumerate(), there are very few assumptions you 
can make about the input without actually running the iteration.  So, I 
don't see how you can change enumerate's repr method unless adopting a 
combination of styles, switching back and forth depending on the input:

>>> enumerate('abcde')
<(0, 'a'), (1, 'b'), ...>
>>> enumerate(open('tmp.txt'))


IMO, switching back and forth is an especially bad idea.
Hence, enumerate's repr ought to be left alone too.


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

[Guido van Rossum]

On 2/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 2/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> > It looks like we need a Python 2.5 Release Schedule PEP.
>
> Very draft: http://www.python.org/peps/pep-0356.html
>
> Needs lots of work and release managers.  Anthony, Martin, Fred, Sean
> are all mentioned with TBDs and question marks.

Before he went off to a boondoggle^Woff-site at a Mexican resort, Neal
made me promise that I'd look at this and try to get the 2.5 release
plan going for real.

First things first: we need a release manager. Anthony, do you want to
do the honors again, or are you ready for retirement?

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.

There's a bunch of sections (some very long) towards the end of the
PEP of questionable use; Neal just copied these from the 2.4 release
schedule (PEP 320):

- Ongoing tasks
- Carryover features from Python 2.4
- Carryover features from Python 2.3 (!)

Can someone go over these and suggest which we should keep, which we
should drop? (I may do this later, but I have other priorities below.)

Then, the list of features that ought to be in 2.5. Quoting Neal's draft:

>PEP 308: Conditional Expressions

Definitely. Don't we have a volunteer doing this now?

>PEP 328: Absolute/Relative Imports

Yes, please.

>PEP 343: The "with" Statement

Didn't Michael Hudson have a patch?

>PEP 352: Required Superclass for Exceptions

I believe this is pretty much non-controversial; it's a much weaker
version of PEP 348 which was rightfully rejected for being too
radical. I've tweaked some text in this PEP and approved it. Now we
need to make it happen. It might be quite a tricky thing, since
Exception is currently implemented in C as a classic class. If Brett
wants to sprint on this at PyCon I'm there to help (Mon/Tue only).
Fortunately we have MWH's patch 1104669 as a starting point.

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

Other PEPs I'd like comment on:

PEP 357 (__index__): the patch isn't on SF yet, but otherwise I'm all
for this, and I'd like to accept it ASAP to get it in 2.5. It doesn't
look like it'll cause any problems.

PEP 314 (metadata v1.1): this is marked as completed, but there's a
newer PEP available: PEP 334 (metadata v1.2). That PEP has 2.5 as its
target date. Shouldn't we implement it? (This is a topic that I
haven't followed closely.) There's also the question whether 314
should be marked final. Andrew or Richard?

PEP 355 (path module): I still haven't reviewed this, because I'm -0
on adding what appears to me duplicate functionality. But if there's a
consensus building perhaps it should be allowed to go forward (and
then I *will* review it carefully).

I found a few more PEPs slated for 2.5 but that haven't seen much action lately:

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?

PEP 349 - str() may return unicode. Where is this? I'm not at all sure
the PEP is ready. it would probably be a lot of work to make this work
everywhere in the C code, not to mention the stdlib .py code. Perhaps
this should be targeted for 2.6 instead? The consequences seem
potentially huge.

PEP 315 - do while. A simple enough syntax proposal, albeit one
introducing a new keyword (which I'm fine with). I kind of like it but
it doesn't strike me as super important -- if we put this off until
Py3k I'd be fine with that too. Opinions? Champions?

Ouch, a grep produced tons more. Quick rundown:

PEP 246 - adaptation. I'm still as lukewarm as ever; it needs
interfaces, promises to cause a paradigm shift, and the global map
worries me.

PEP 323 - copyable iterators. Seems stalled. Alex, do you care?

PEP 332 - byte vectors. Looks incomplete. Put off until 2.6?

PEP 337 - logging in the stdlib. What of it? This seems a good idea
but potentially disruptive (because backwards incompatible). Also it
could be done piecemeal on an opportunistic basis. Any volunteers?

PEP 338 - support -m for modules in packages. I believe Nick Coghlan
is close to implementing this. I'm fine with accepting it.

PEP 344 - exception chaining. There are deep problems with this d

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

[Scott Dial]

Tim Peters wrote:
> No more than it had been jarred ;-)  Well, a bit more:  it was
> possible to pass a first argument to select() that was larger than
> FD_SETSIZE.  In effect, FD_SETSIZE had no meaning.

This begs the question then whether the check that is implemented has 
any relevance to any platform other than Linux. I am no portability 
guru, but I have to think there are other platforms where this patch 
will cause problems. For now at least, can we at least do some 
preprocessing magic to not use this code with Windows?

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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

[Thomas Wouters]

On Fri, Feb 10, 2006 at 03:24:28PM -0500, Scott Dial wrote:
> Tim Peters wrote:
> >No more than it had been jarred ;-)  Well, a bit more:  it was
> >possible to pass a first argument to select() that was larger than
> >FD_SETSIZE.  In effect, FD_SETSIZE had no meaning.
> 

> any relevance to any platform other than Linux. I am no portability 
> guru, but I have to think there are other platforms where this patch 
> will cause problems. For now at least, can we at least do some 
> preprocessing magic to not use this code with Windows?

I doubt it will have problems on other platforms. As Tim said, FD_SETSIZE is
mandated by POSIX. Perhaps some platforms do allow larger sizes, by
replacing the FD_* macros with functions that dynamically grow whatever
magic is the 'fdset' datatype. I sincerely doubt it's a common approach,
though, and for them to be POSIX they would need to have FD_SETSIZE set to
some semi-sane value. So at worst, on those platforms (if any), we're
reducing the number of sockets you can actually select() on, from some
undefined platform maximum to whatever the platform *claims* is the maximum.

-- 
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] ssize_t status (Was: release plan for 2.5 ?)

[Martin v. Löwis]

Guido van Rossum wrote:
>>   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?

"It works", in a way. You only get the tons of warnings with the
right compiler, and you don't actually need to fix them all to get
something useful. Not all modules need to be converted to support
more than 2**31 elements for all containers they operate on, so
this could also be based on user feedback.

Some users (so far, just Marc-Andre) have complained that this
breaks backwards compatibility. Some improvements can be made still,
but for some aspects (tp_as_sequence callbacks), I think the best
we can hope for is compiler warnings about incorrect function
pointer types.

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

Sure: I hope to complete this all in March.

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

[Martin v. Löwis]

Scott Dial wrote:
> This begs the question then whether the check that is implemented has 
> any relevance to any platform other than Linux. I am no portability 
> guru, but I have to think there are other platforms where this patch 
> will cause problems.

The patch is right on all platforms conforming to the POSIX standard.
POSIX says that FD_ISSET and friends have undefined behaviour if
the file descriptor is larger than FD_SETSIZE.

For platforms not conforming to the POSIX standard, the patch errs
on the conservative side: it refuses to do something that POSIX
says has undefined behaviour, yet may be well-defined on that
platform.

Disabling this for Windows is fine with me; I also think there should
be some kind of documentation that quickly shows the potential cause
of the exception

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

[Martin v. Löwis]

Thomas Wouters wrote:
> I doubt it will have problems on other platforms. As Tim said, FD_SETSIZE is
> mandated by POSIX. Perhaps some platforms do allow larger sizes, by
> replacing the FD_* macros with functions that dynamically grow whatever
> magic is the 'fdset' datatype. I sincerely doubt it's a common approach,
> though, and for them to be POSIX they would need to have FD_SETSIZE set to
> some semi-sane value. So at worst, on those platforms (if any), we're
> reducing the number of sockets you can actually select() on, from some
> undefined platform maximum to whatever the platform *claims* is the maximum.

I think the Windows interpretation is actually well-designed: FD_SETSIZE
shouldn't be the number of the largest descriptor, but instead be the
maximum size of the set. So FD_SETSIZE is 64 on Windows, but you still
can have much larger file descriptor numbers.

The implementation strategy of Windows is to use an array of integers,
rather than the bit mask, and an index telling you how many slots have
already been filled. With FD_SETSIZE being 64, the fd_set requires
256 bytes.

This strategy has a number of interesting implications:
- a naive implementation of FD_SET is not idempotent; old winsock
  implementations where so naive. So you might fill the set by
  setting the same descriptor 64 times. Current implementations
  use a linear search to make the operation idempotent.
- FD_CLR needs to perform a linear scan for the descriptor,
  and then shift all subsequent entries by one (it could actually
  just move the very last entry to the deleted slot, but doesn't)

In any case, POSIX makes it undefined what FD_SET does when the
socket is larger than FD_SETSIZE, and apparently clearly expects
an fd_set to be a bit mask.

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] compiler.pyassem

[Fabiano Sidler]

Hi folks!

Do I see things as they are and compiler.pyassem generates bytecode
straight without involve any C code, i.e. code from the VM or the
compiler? How is this achieved? I took a look at Python/compile.c as
mentioned in compiler.pyassem and I'm trying to get into it, but about
6500 lines of C code are too much for me in one file. Could someone
here please give me some hints on how one can do what compiler.pyassem
does?

Greetings,
Fips
___
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 ?

[Raymond Hettinger]

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



> PEP 315 - do while. A simple enough syntax proposal, albeit one
> introducing a new keyword (which I'm fine with). I kind of like it but
> it doesn't strike me as super important -- if we put this off until
> Py3k I'd be fine with that too. Opinions? Champions?

I helped tweak a few issues with the PEP and got added as a co-author.
I didn't push for it because the syntax is a little odd if nothing appears 
in
the while suite:

do:
val = source.read(1)
process(val)
while val != lastitem:
pass

I never found a way to improve this.  Dropping the final colon and 
post-while
steps improved the looks but diverged too far away from the rest of the 
language:

do:
val = source.read(1)
process(val)
while val != lastitem

So, unless another champion arises, putting this off until Py3k is fine with 
me.



 > PEP 323 - copyable iterators. Seems stalled. Alex, do you care?

I installed the underlying mechanism in support of itertools.tee() in Py2.4.

So, if anyone really wants to make xrange() copyable, it is now a trivial 
task --
likewise for any other iterator that has a potentially copyable state.

I've yet to find a use case for it, so I never pushed for the rest of
the PEP to be implemented.  There's nothing wrong with the idea,
but there doesn't seem to be much interest.



> PEP 344 - exception chaining. There are deep problems with this due to
> circularities; perhaps we should drop this, or revisit it for Py3k.

I wouldn't hold-up Py2.5 for this.

My original idea for this was somewhat simpler.  Essentially, a high-level 
function would concatenate extra string information onto the result of an 
exception raised at a lower level.  That strategy was applied to an existing 
problem for type objects and has met with good success.

IOW, there is a simpler alternative on the table, but resolution won't take 
place until we collectively take interest in it again.  At this point, it 
seems to be low on everyone's priority list (including mine).



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

[Phillip J. Eby]

At 12:21 PM 2/10/2006 -0800, Guido van Rossum wrote:
> >PEP 343: The "with" Statement
>
>Didn't Michael Hudson have a patch?

PEP 343's "Accepted" status was reverted to "Draft" in October, and then 
changed back to "Accepted".  I believe the latter change is an error, since 
you haven't pronounced on the changes.  Have you reviewed the __context__ 
stuff that was added?

In any case Michael's patch was pre-AST branch merge, and no longer 
reflects the current spec.


>PEP 332 - byte vectors. Looks incomplete. Put off until 2.6?

Wasn't the plan to just make this a builtin version of array.array for 
bytes, plus a .decode method and maybe a few other tweaks?  We presumably 
won't be able to .encode() to bytes or get bytes from sockets and files 
until 3.0, but having the type and being able to write it to files and 
sockets would be nice.  I'm not sure about the b"" syntax, ISTR it was 
controversial but I don't remember if there was a resolution.


>PEP 314 (metadata v1.1): this is marked as completed, but there's a
>newer PEP available: PEP 334 (metadata v1.2). That PEP has 2.5 as its
>target date. Shouldn't we implement it? (This is a topic that I
>haven't followed closely.) There's also the question whether 314
>should be marked final. Andrew or Richard?

I'm concerned that both metadata PEPs push to define syntax for things that 
have undefined semantics.  And worse, to define incompatible syntax in some 
cases.  PEP 345 for example, dictates the use of StrictVersion syntax for 
the required version of Python and the version of external requirements, 
but Python's own version numbers don't conform to strict version 
syntax.  ISTM that the metadata standard needs more work, especially since 
PyPI doesn't actually support using all of the metadata provided by the 
implemented version of the standard.  There's no way to search for 
requires/provides, for example (which is one reason why I went with 
distribution names for dependency resolution in setuptools).  Also, the 
specs don't allow for a Maintainer distinct from the package Author, even 
though the distutils themselves allow this.  IMO, 345 needs to go back to 
the drawing board, and I'm not really thrilled with the currently-useless 
"requires/provides" stuff in PEP 314.

If we do anything with the package metadata in Python 2.5, I'd like it to 
be *installing* PKG-INFO files alongside the packages, using a filename of 
the form "distributionname-version-py2.5.someext".  Setuptools supports 
such files currently under the ".egg-info" extension, but I'd be just as 
happy with '.pkg-info' if it becomes a Python standard addition to the 
installation.  Having this gives most of the benefits of PEP 262 (database 
of installed packages), although I wouldn't mind extending the PKG-INFO 
file format to include some of the PEP 262 additional data.

These are probably distutils-sig and/or catalog-sig topics; I just mainly 
wanted to point out that 314, 245, and 262 need at least some tweaking and 
possibly rethinking before any push to implementation.

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

[Thomas Wouters]

On Fri, Feb 10, 2006 at 12:21:26PM -0800, Guido van Rossum wrote:

> ??? Would anyone want to be even more aggressive (e.g. alpha 1 right
> after PyCon???). We could always do three alphas.

Well, PyCon might be a nice place to finish any PEP patches. I know I'll be
available to do such work on the sprint days ;) I don't think that means
we'll have a working repository with all 2.5 features right after, though.

> >PEP 308: Conditional Expressions

> Definitely. Don't we have a volunteer doing this now?

There is a volunteer, but he's new at this, so he probably needs a bit of
time to work through the intricacies of the AST, the compiler and the eval
loop.

-- 
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] compiler.pyassem

[Jeremy Hylton]

On 2/10/06, Fabiano Sidler <[EMAIL PROTECTED]> wrote:
> Do I see things as they are and compiler.pyassem generates bytecode
> straight without involve any C code, i.e. code from the VM or the
> compiler? How is this achieved? I took a look at Python/compile.c as
> mentioned in compiler.pyassem and I'm trying to get into it, but about
> 6500 lines of C code are too much for me in one file. Could someone
> here please give me some hints on how one can do what compiler.pyassem
> does?

I'm not sure what exactly you want to know.  The compiler package
implements most of a Python bytecode compiler in Python.  It re-uses
the parser written in C, but otherwise does the entire transformation
in Python.  The "how is this achieved?" question is hard to answer
without saying "read the source."  There are about 6000 lines of
Python code in the compiler pacakge, but you can largely ignore ast.py
and transformer.py if you just want to study the compiler.

Perhaps you specific question is: How does the interpreter create new
bytecode or function objects from a program instead of compiling from
source or importing a module?  At some level, bytecode is simply a
string representation of a progam.  The new module takes the bytecode
plus a lot of meta-data including the names of variables and a list of
constants, and produces a new code object.  See the newCodeObject()
method.

I suspect further discussion on this topic might be better done on
python-list, unless you have some discussion that is relevant for
Python implementors.

Jeremy
___
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]

[Scott Dial]
> This begs the question then whether the check that is implemented has
> any relevance to any platform other than Linux. I am no portability
> guru, but I have to think there are other platforms where this patch
> will cause problems. For now at least, can we at least do some
> preprocessing magic to not use this code with Windows?

We _have_ to gut this patch on Windows, because Python code using
sockets on Windows no longer works.  That can't stand.  Indeed, I'm
half tempted to revert the checkin right now since Python's test suite
fails or hangs on Windows in test after test now.  This at least
blocks me from doing work I wanted to do (instead I spent the time
allocated for that staring at test failures).

I suggest skipping the new crud conditionalized on a symbol like

Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE

The Windows pyconfig.h can #define that, and other platforms can
ignore its possible existence.  If it applies to some Unix variant
too, fine, that variant can also #define it.  No idea here what the
story is on, e.g., Cygwin or OS2.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

On 2/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:

I'm not following up to anything that Phillip wrote (yet), but his
response reminded me of two more issues:

- wsgiref, an implementation of PEP 333 (Web Standard Gateway
interface). I think this might make a good addition to the standard
library. The web-sig has been discussing additional things that might
be proposed for addition but I believe there's no consensus -- in any
case we ought to be conservative.

- setuplib? Wouldn't it make sense to add this to the 2.5 stdlib?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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:
> I suggest skipping the new crud conditionalized on a symbol like
> 
> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
> 

Hmm... How about this patch:

Index: Modules/socketmodule.c
===
--- Modules/socketmodule.c  (Revision 42308)
+++ Modules/socketmodule.c  (Arbeitskopie)
@@ -396,7 +396,14 @@
 static PyTypeObject sock_type;

 /* Can we call select() with this socket without a buffer overrun? */
+#ifdef MS_WINDOWS
+/* Everything is selectable on Windows */
+#define IS_SELECTABLE(s)  1
+#else
+/* POSIX says selecting descriptors above FD_SETSIZE is undefined
+   behaviour. */
 #define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE)
+#endif

 static PyObject*
 select_error(void)

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]
> I think the Windows interpretation is actually well-designed: FD_SETSIZE
> shouldn't be the number of the largest descriptor, but instead be the
> maximum size of the set.

It's more that the fdset macros were well designed:  correct code
using FD_SET() etc is portable across Windows and Linux, and that's so
because the macros define an interface rather than an implementation. 
BTW, note that the first argument to select() is ignored on Windows.

> So FD_SETSIZE is 64 on Windows,

In Python FD_SETSIZE is 512 on Windows (see the top of selectmodule.c).

> but you still can have much larger file descriptor numbers.

Which is the _source_ of "the problem" on Windows:  Windows socket
handles aren't file descriptors (if they were, they'd be little
integers ;-)).

> ...
> In any case, POSIX makes it undefined what FD_SET does when the
> socket is larger than FD_SETSIZE, and apparently clearly expects
> an fd_set to be a bit mask.

Yup -- although the people who designed the fdset macros to begin with
didn't appear to have this assumption.
___
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

[Scott Dial]

Martin v. Löwis wrote:
> Tim Peters wrote:
>> I suggest skipping the new crud conditionalized on a symbol like
>>
>> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
>>
> 
> Hmm... How about this patch:
> 
> Index: Modules/socketmodule.c
> ===
> --- Modules/socketmodule.c  (Revision 42308)
> +++ Modules/socketmodule.c  (Arbeitskopie)
> @@ -396,7 +396,14 @@
>  static PyTypeObject sock_type;
> 
>  /* Can we call select() with this socket without a buffer overrun? */
> +#ifdef MS_WINDOWS
> +/* Everything is selectable on Windows */
> +#define IS_SELECTABLE(s)  1
> +#else
> +/* POSIX says selecting descriptors above FD_SETSIZE is undefined
> +   behaviour. */
>  #define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE)
> +#endif
> 
>  static PyObject*
>  select_error(void)
> 
> Regards,
> Martin

That is the exact patch I applied, but you also need to patch _ssl.c

--- C:/python-trunk/Modules/_ssl.c  (revision 42305)
+++ C:/python-trunk/Modules/_ssl.c  (working copy)
@@ -376,9 +376,11 @@
if (s->sock_fd < 0)
return SOCKET_HAS_BEEN_CLOSED;

+#ifndef MS_WINDOWS
/* Guard against socket too large for select*/
if (s->sock_fd >= FD_SETSIZE)
return SOCKET_INVALID;
+#endif

/* Construct the arguments to select */
tv.tv_sec = (int)s->sock_timeout;


But then that leaves whether to go with the 
Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE symbol instead of MS_WINDOWS.

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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

[Scott Dial]

Tim Peters wrote:
> [Martin v. Löwis]
>> So FD_SETSIZE is 64 on Windows,
> 
> In Python FD_SETSIZE is 512 on Windows (see the top of selectmodule.c).
> 

Although I agree, in terms of the socketmodule, there was no such define 
overriding the default FD_SETSIZE, so you are both right.

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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]
>> I suggest skipping the new crud conditionalized on a symbol like
>>
>> Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE

[Martin]
> Hmm... How about this patch:

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.  If the initial

#ifdef MS_WINDOWS

here gets duplicated in multiple modules (and looks like it must -- or
IS_SELECTABLE should be given a _Py name and defined once in pyport.h
instead), and gets hairier over time, then I'd rather have a name like
the one I suggested (to describe the _intent_ rather than paste
together a growing collection of "which platform do I think I'm being
compiled on?" names).

> Index: Modules/socketmodule.c
> ===
> --- Modules/socketmodule.c  (Revision 42308)
> +++ Modules/socketmodule.c  (Arbeitskopie)
> @@ -396,7 +396,14 @@
>  static PyTypeObject sock_type;
>
>  /* Can we call select() with this socket without a buffer overrun? */
> +#ifdef MS_WINDOWS
> +/* Everything is selectable on Windows */
> +#define IS_SELECTABLE(s)  1
> +#else
> +/* POSIX says selecting descriptors above FD_SETSIZE is undefined
> +   behaviour. */
>  #define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE)
> +#endif
>
>  static PyObject*
>  select_error(void)
___
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]
>>> So FD_SETSIZE is 64 on Windows,

[Tim Peters]
>> In Python FD_SETSIZE is 512 on Windows (see the top of selectmodule.c).

[Scott Dial]
> Although I agree, in terms of the socketmodule, there was no such define
> overriding the default FD_SETSIZE, so you are both right.

?  Sorrry, don't know what you're talking about here.  Python's
selectmodule.c #defines FD_SETSIZE before it includes winsock.h on
Windows, so Microsoft's default is irrelevant to Python.  The reason
selectmodule.c uses "!defined(FD_SETSIZE)" in its

#if defined(MS_WINDOWS) && !defined(FD_SETSIZE)
#define FD_SETSIZE 512
#endif

is explained in the comment right before that code.
___
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 ?

[Barry Warsaw]

On Feb 10, 2006, at 3:21 PM, Guido van Rossum wrote:
>
> 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?

I have no interest in it any longer, and wouldn't shed a tear if it  
were rejected.

One other un-PEP'd thing.  I'd like to put email 3.1 in Python 2.5  
with the new module naming scheme.  The old names will still work,  
and all the unit tests pass.  Do we need a PEP for that?

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

[M.-A. Lemburg]

Guido van Rossum wrote:
>>PEP 328: Absolute/Relative Imports
> 
> Yes, please.

+0 for adding relative imports. -1 for raising errors for
in-package relative imports using the current notation
in Python 2.6.

See:

http://mail.python.org/pipermail/python-dev/2004-September/048695.html

for a previous discussion.

The PEP still doesn't have any mention of the above discussion or
later follow-ups.

The main argument is that the strategy to make absolute imports
mandatory and offer relative imports as work-around breaks the
possibility to produce packages that work in e.g. Python 2.4 and
2.6, simply because Python 2.4 doesn't support the needed
relative import syntax.

The only strategy left would be to use absolute imports throughout,
which isn't all that bad, except when it comes to relocating a
package or moving a set of misc. modules into a package - which is
not all that uncommon in larger projects, e.g. to group third-party
top-level modules into a package to prevent cluttering up the
top-level namespace or to simply make a clear distinction in
your code that you are relying on a third-party module, e.g

from thirdparty import tool

I don't mind having to deal with a warning for these, but don't
want to see this raise an error before Py3k.

-- 
Marc-Andre Lemburg
eGenix.com

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


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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 ?

[Thomas Wouters]

On Fri, Feb 10, 2006 at 11:06:24PM +0100, M.-A. Lemburg wrote:
> Guido van Rossum wrote:
> >>PEP 328: Absolute/Relative Imports
> > 
> > Yes, please.

> +0 for adding relative imports. -1 for raising errors for
> in-package relative imports using the current notation
> in Python 2.6.

+1/-1 for me. Being able to explicitly demand relative imports is good,
breaking things soon bad. I'll happily shoehorn this in at the sprints after
PyCon ;)

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

[Guido van Rossum]

On 2/10/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 10, 2006 at 11:06:24PM +0100, M.-A. Lemburg wrote:
> > Guido van Rossum wrote:
> > >>PEP 328: Absolute/Relative Imports
> > >
> > > Yes, please.
>
> > +0 for adding relative imports. -1 for raising errors for
> > in-package relative imports using the current notation
> > in Python 2.6.
>
> +1/-1 for me. Being able to explicitly demand relative imports is good,
> breaking things soon bad. I'll happily shoehorn this in at the sprints after
> PyCon ;)

The PEP has the following timeline (my interpretation):

2.4: implement new behavior with from __future__ import absolute_import
2.5: deprecate old-style relative import unless future statement present
2.6: disable old-style relative import, future statement no longer necessary

Since it wasn't implemented in 2.4, I think all these should be bumped
by one release. Aahz, since you own the PEP, can you do that (and make
any other updates that might result)?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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 ?

[Raymond Hettinger]

[Barry Warsaw"]like to put email 3.1 in Python 2.5  
> with the new module naming scheme.  The old names will still work,  
> and all the unit tests pass.  Do we need a PEP for that?

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

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

[Guido van Rossum]

On 2/10/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Barry Warsaw"]like to put email 3.1 in Python 2.5
> > with the new module naming scheme.  The old names will still work,
> > and all the unit tests pass.  Do we need a PEP for that?
>
> +1

I don't know if Raymond meant "we need a PEP" or "go ahead with the
feature" but my own feeling is that this doesn't need a PEP and Barry
can Just Do It.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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:
> 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?

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

[Alex Martelli]

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:

October would seem to me to be just about right.  I don't see that one
month either way should make any big difference, though.

> ??? Would anyone want to be even more aggressive (e.g. alpha 1 right
> after PyCon???). We could always do three alphas.

If I could have a definitive frozen list of features by the first week
of April at the latest, that could make it (as a "2.5 preview") into
the 2nd edition of "Python in a Nutshell". But since alphas are not
feature-frozen, it wouldn't make much of a difference to me, I think.

> Other PEPs I'd like comment on:
>
> PEP 357 (__index__): the patch isn't on SF yet, but otherwise I'm all
> for this, and I'd like to accept it ASAP to get it in 2.5. It doesn't
> look like it'll cause any problems.

It does look great, and by whatever name I support it most heartily. 
Do, however, notice that it's "yet another specialpurpose adaptation
protocol" and that such specific restricted solutions to the general
problem, with all of their issues, will just keep piling up forever
(and need legacy support ditto) until and unless your temperature wrt
246 (or any variation thereof) should change.

> PEP 355 (path module): I still haven't reviewed this, because I'm -0
> on adding what appears to me duplicate functionality. But if there's a

I feel definitely -0 towards it too.

> PEP 315 - do while. A simple enough syntax proposal, albeit one
> introducing a new keyword (which I'm fine with). I kind of like it but
> it doesn't strike me as super important -- if we put this off until
> Py3k I'd be fine with that too. Opinions? Champions?

Another -0 from me. I suggest we shelve it for now and revisit in 3k
(maybe PEPs in that state, "not in any 2.* but revisit for 3.0", need
a special status value).

> PEP 246 - adaptation. I'm still as lukewarm as ever; it needs
> interfaces, promises to cause a paradigm shift, and the global map
> worries me.

Doesn't _need_ interfaces as a concept -- any unique markers as
"protocol names" would do, even strings, although obviously the
"stronger" the markers the better (classes/types for example would be
just perfect).  It was written on the assumption of interfaces just
because they were being proposed just before it.  The key "paradigm
shift" is to offer a way to unify what's already being widely done, in
haphazard and dispersed manners.  And I'll be quite happy to rewrite
it in terms of a more nuanced hierarchy of maps (e.g. builtin /
per-module / lexically nested, or whatever) if that's what it takes to
warm you to it -- I just think it would be over-engineering it, since
in practice the global-on-all-modules map would cover by far most
usage (both for "blessed" protocols that come with Python, and for the
use of "third party" adapting framework A to consume stuff that
framework B produces, global is the natural "residence"; other uses
are far less important.


> PEP 323 - copyable iterators. Seems stalled. Alex, do you care?

Sure, I'd like to make this happen, particularly since Raymond appears
to have already done the hard part.  What would you like to see
happening to bless it for 2.5?

> PEP 332 - byte vectors. Looks incomplete. Put off until 2.6?

Ditto -- I'd like at least SOME of it to be in 2.5.  What needs to
happen for that?


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

[Thomas Wouters]

On Fri, Feb 10, 2006 at 02:45:54PM -0800, Guido van Rossum wrote:

> The PEP has the following timeline (my interpretation):
> 
> 2.4: implement new behavior with from __future__ import absolute_import
> 2.5: deprecate old-style relative import unless future statement present
> 2.6: disable old-style relative import, future statement no longer necessary

> Since it wasn't implemented in 2.4, I think all these should be bumped
> by one release. Aahz, since you own the PEP, can you do that (and make
> any other updates that might result)?

Bumping is fine (of course), but I'd like a short discussion on the actual
disabling before it happens (rather than the disabling happening without
anyone noticing until beta2.) There seem to be a lot of users still using
2.3, at the moment, in spite of its age. Hopefully, by the time 2.7 comes
out, everyone will have switched to 2.5, but if not, it could still be a
major annoyance to conscientious module-writers, like MAL.

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

[Brett Cannon]

On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > On 2/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> > > It looks like we need a Python 2.5 Release Schedule PEP.
> >
> > Very draft: http://www.python.org/peps/pep-0356.html
> >
> > Needs lots of work and release managers.  Anthony, Martin, Fred, Sean
> > are all mentioned with TBDs and question marks.
>
> Before he went off to a boondoggle^Woff-site at a Mexican resort, Neal
> made me promise that I'd look at this and try to get the 2.5 release
> plan going for real.
>
> First things first: we need a release manager. Anthony, do you want to
> do the honors again, or are you ready for retirement?
>
> 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 think that schedule is fine, but going alpha after PyCon is too fast
with the number of PEPs that need implementing.
[SNIP]
> >PEP 352: Required Superclass for Exceptions
>
> I believe this is pretty much non-controversial; it's a much weaker
> version of PEP 348 which was rightfully rejected for being too
> radical. I've tweaked some text in this PEP and approved it. Now we
> need to make it happen. It might be quite a tricky thing, since
> Exception is currently implemented in C as a classic class. If Brett
> wants to sprint on this at PyCon I'm there to help (Mon/Tue only).
> Fortunately we have MWH's patch 1104669 as a starting point.
>

I might sprint on it.  It's either this or I will work on the AST
stuff (the PyObject branch is still not finishd and thus it has not
been finalized if that solution or the way it is now will be the final
way of implementing the compiler and I would like to see this
settled).

Either way I take responsibility to make sure the PEP gets implemented
so you can take that question off of the schedule PEP.

[SNIP]
> 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?
>

If Barry doesn't even care anymore I say kill it.

[SNIP]
> PEP 315 - do while. A simple enough syntax proposal, albeit one
> introducing a new keyword (which I'm fine with). I kind of like it but
> it doesn't strike me as super important -- if we put this off until
> Py3k I'd be fine with that too. Opinions? Champions?
>

Eh, seems okay but I am not jumping up and down for it.  Waiting until
Python 3 is fine with me if a discussion is warranted (don't really
remember it coming up before).
[SNIP]
> PEP 332 - byte vectors. Looks incomplete. Put off until 2.6?
>

I say put off.  This could be discussed at PyCon since this might be
an important type to get right.

[SNIP]
> PEP 344 - exception chaining. There are deep problems with this due to
> circularities; perhaps we should drop this, or revisit it for Py3k.
>

I say revisit issues later.  Raymond says he has an idea for chaining
just the messages which could be enough help for developers.  But
either way I don't think this has been hashed out enough to go in
as-is.  I suspect a simpler solution will work, such as ditching the
traceback and only keeping either the text that would have been
printed or just the exception instance (and thus also its message).

-Brett
___
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 ?

[Barry Warsaw]

On Feb 10, 2006, at 5:47 PM, Guido van Rossum wrote:

> On 2/10/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> [Barry Warsaw"]like to put email 3.1 in Python 2.5
>>> with the new module naming scheme.  The old names will still work,
>>> and all the unit tests pass.  Do we need a PEP for that?
>>
>> +1
>
> I don't know if Raymond meant "we need a PEP" or "go ahead with the
> feature" but my own feeling is that this doesn't need a PEP and Barry
> can Just Do It.

I was going to ask the same thing. :)

Cool.  So far there have been no objections on the email-sig, so I'll  
try to move the sandbox to the trunk this weekend.  That should give  
us plenty of time to shake out any nastiness.

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

[Raymond Hettinger]

Just do it.

- Original Message - 
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Barry Warsaw" <[EMAIL PROTECTED]>; 
Sent: Friday, February 10, 2006 5:47 PM
Subject: Re: [Python-Dev] release plan for 2.5 ?


On 2/10/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Barry Warsaw"]like to put email 3.1 in Python 2.5
> > with the new module naming scheme.  The old names will still work,
> > and all the unit tests pass.  Do we need a PEP for that?
>
> +1

I don't know if Raymond meant "we need a PEP" or "go ahead with the
feature" but my own feeling is that this doesn't need a PEP and Barry
can Just Do It.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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:

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

(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!)

Sorry, I just had to say that.

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

[Greg Ewing]

Tim Peters wrote:
> [Martin v. Löwis]
> > In any case, POSIX makes it undefined what FD_SET does when the
> > socket is larger than FD_SETSIZE, and apparently clearly expects
> > an fd_set to be a bit mask.
> 
> Yup -- although the people who designed the fdset macros to begin with
> didn't appear to have this assumption.

I don't agree. I rather think the entire purpose of
the fdset interface was simply to allow more than
32 items in the set (which the original select()
in BSD was limited to). The whole thing still seems
totally bitmask-oriented, down to the confusion between
set size and file descriptor number.

The MacOSX man page for select() (which seems fairly
closely BSD-based) even explicitly says "The descriptor
sets are stored as bit fields in arrays of integers."

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

[Tim Peters]

[Martin v. Löwis]
> I see. How does Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE help here?

By naming a logical condition as opposed to a list of
platform-specific symbols that aren't documented anywhere.  For
example, I have no idea exactly which compiler+OS combinations define
MS_WINDOWS, so "#ifdef MS_WINDOWS" is always something of a mystery. 
I don't want to see mystery-symbols inside modules -- to the extent
that they must be used, I want to hide them in .h files clearly
dedicated to wrestling with portability headaches (like pyconfig.h and
pyport.h).

> Does defining it in PC/pyconfig.h do the right thing?

That much would stop the test failures _I_ see, which is what I need
to get unstuck.  If POSIX systems simply ignore it, it would do the
right thing for them too.  Documentation in pyport.h would serve to
guide others (in the "Config #defines referenced here:" comments near
the top of that file).  I don't know what other systems need, so
assuming "we have to do something" _at all_ here, the best I can do is
provide documented macros and config symbols to deal with it.

I think the relationship between SIGNED_RIGHT_SHIFT_ZERO_FILLS and
pyport.h's Py_ARITHMETIC_RIGHT_SHIFT macro is a good analogy here. 
Almost everyone ignores SIGNED_RIGHT_SHIFT_ZERO_FILLS, and that's
fine, because almost all C compilers generate code to do
sign-extending right shifts.  If someone has a box that doesn't, fine,
it's up to them to get SIGNED_RIGHT_SHIFT_ZERO_FILLS #define'd in
their pyconfig.h, and everything else "just works" for them then.  All
other platforms can remain blissfully ignorant.

> I guess I'm primarily opposed to the visual ugliness of the define.

I don't much care how it's spelled.

> Why does it spell out "can be", but abbreviates
> "greater than or equal to"?

Don't care.  I don't know of a common abbrevation for "can be", but GE
same-as >= is in my Fortran-trained blood :-)

> What about Py_CHECK_FD_SETSIZE?

That's fine, except I think it would be pragmatically better to make
it Py_DONT_CHECK_FD_SETSIZE, since most platforms want to check it. 
The platforms that don't want this check (like Windows) are the
oddballs, so it's better to default to checking, making the oddballs
explicitly do something to stop such checking.

It's no problem to add a #define to PC/pyconfig.h, since that
particular config file is 100% hand-written (and always will be).
___
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 17:53:39 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:

>On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote:
>> On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > OMG. Are we now adding 'const' modifiers to random places? I thought
>> > "const propagation hell" was a place we were happily avoiding by not
>> > falling for that meme. What changed?
>> 
>> I added some const to several API functions that take char* but
>> typically called by passing string literals.  In C++, a string literal
>> is a const char* so you need to add a const_cast<> to every call site,
>> which is incredibly cumbersome.  After some discussion on python-dev,
>> I made changes to a small set of API functions and chased the
>> const-ness the rest of the way, as you would expect.  There was
>> nothing random about the places const was added.
>> 
>> 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.
>
>Well, it's counter-intuitive, but a direct result of how pointer equivalence
>is defined in C. I'm rusty in this part, so I will get some terminology
>wrong, but IIRC, a variable A is of an equivalent type of variable B if they
>hold the same type of data. So, a 'const char *' is equivalent to a 'char *'
>because they both hold the memory of a 'char'. But a 'const char**' (or
>'const *char[]') is not equivalent to a 'char **' (or 'char *[]') because
>the first holds the address of a 'const char *', and the second the address
>of a 'char *'. A 'char * const *' is equivalent to a 'char **' though.
>
>As I said, I got some of the terminology wrong, but the end result is
>exactly that: a 'const char **' is not equivalent to a 'char **', even
>though a 'const char *' is equivalent to a 'char *'. Equivalence, in this
>case, means 'can be automatically downcasted'. Peter v/d Linden explains
>this quite well in "Expert C Programming" (aka 'Deep C Secrets'), but
>unfortunately I'm working from home and I left my copy at a coworkers' desk.
>
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 ;-)

Regards,
Bengt Richter

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

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

[Scott Dial]

Tim Peters wrote:
> ?  Sorrry, don't know what you're talking about here.  Python's
> selectmodule.c #defines FD_SETSIZE before it includes winsock.h on
> Windows, so Microsoft's default is irrelevant to Python.  The reason
> selectmodule.c uses "!defined(FD_SETSIZE)" in its

Not that this is really that important, but if we are talking about as 
the code stands right now, IS_SELECTABLE uses FD_SETSIZE with no such 
define ever appearing. That is what I meant, and I am pretty sure that 
is where Martin came up with saying it was 64. But like I say.. it's not 
that important. Sorry for the noise.

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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

[Scott Dial]

Tim Peters wrote:
 > Does it do the right thing for Windows variants like Cygwin, and OS/2?

I can at least say that the Cygwin implements a full POSIX facade in 
front of Windows sockets, so it would be important that the code in 
question is used to protect it as well. Also, MS_WINDOWS is not defined 
for a Cygwin compile, so it is fine to be using that. But I realize 
there is a whole 'nother discussion about that.

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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 ?

[Neil Schemenauer]

Guido van Rossum <[EMAIL PROTECTED]> wrote:
> PEP 349 - str() may return unicode. Where is this?

Does that mean you didn't find and read the PEP or was it written so
badly that it answered none of your questions?  The PEP is on
python.org with all the rest.  I set the status to "Deferred"
because it seemed that no one was interested in the change.

> I'm not at all sure the PEP is ready. it would probably be a lot
> of work to make this work everywhere in the C code, not to mention
> the stdlib .py code. Perhaps this should be targeted for 2.6
> instead? The consequences seem potentially huge.

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.

  Neil

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

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

[Guido van Rossum]

On 2/10/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > PEP 349 - str() may return unicode. Where is this?
>
> Does that mean you didn't find and read the PEP or was it written so
> badly that it answered none of your questions?  The PEP is on
> python.org with all the rest.  I set the status to "Deferred"
> because it seemed that no one was interested in the change.

Sorry -- it was an awkward way to ask "what's the status"? You've answered that.

> > I'm not at all sure the PEP is ready. it would probably be a lot
> > of work to make this work everywhere in the C code, not to mention
> > the stdlib .py code. Perhaps this should be targeted for 2.6
> > instead? The consequences seem potentially huge.
>
> 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.

So let's think about this more post 2.5.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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 ?

[Bengt Richter]

On Sat, 11 Feb 2006 05:08:09 + (UTC), Neil Schemenauer <[EMAIL PROTECTED]> 
wrote:

>Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> PEP 349 - str() may return unicode. Where is this?
>
>Does that mean you didn't find and read the PEP or was it written so
>badly that it answered none of your questions?  The PEP is on
>python.org with all the rest.  I set the status to "Deferred"
>because it seemed that no one was interested in the change.
>
>> I'm not at all sure the PEP is ready. it would probably be a lot
>> of work to make this work everywhere in the C code, not to mention
>> the stdlib .py code. Perhaps this should be targeted for 2.6
>> instead? The consequences seem potentially huge.
>
>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.
>
Should this not be coordinated with PEP 332?

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

[Guido van Rossum]

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

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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