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
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.
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
[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
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
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
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
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
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
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
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.
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
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
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
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
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
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?
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.
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
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
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
[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.
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
[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*
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
[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
[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
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
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
[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]
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
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
[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
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
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
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
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
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
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
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
[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
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
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
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
[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
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
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
[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
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
===
---
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
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
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
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
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
[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
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
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
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
Next, the schedule. Neal's draft of the schedule has us releasing 2.5
in October. That feels late -- nearly two years after 2.4 (which was
released on Nov 30, 2004). Do people think it's reasonable to strive
for a more aggressive (by
On 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
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
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
Just do it.
- Original Message -
From: Guido van Rossum [EMAIL PROTECTED]
To: Raymond Hettinger [EMAIL PROTECTED]
Cc: Barry Warsaw [EMAIL PROTECTED]; python-dev@python.org
Sent: Friday, February 10, 2006 5:47 PM
Subject: Re: [Python-Dev] release plan for 2.5 ?
On 2/10/06, Raymond
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. stdio.h)
Things like this are really starting to get on my groat.
It
[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
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
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
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
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
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
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?
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
71 matches
Mail list logo
