> 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
> >
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 que
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
> pyt
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
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 def
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 reall
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
[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_WIN
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
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 use
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 <[EMA
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?
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
> >
> > Ne
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-sty
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 aggressiv
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_SETS
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
[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
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 rel
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
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 pr
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 rej
[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.
? Sor
[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
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 Di
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
> ===
>
[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 Wi
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 (Revisi
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
libra
[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
> prepro
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
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
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 pronou
[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
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
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'
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 confo
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
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 pl
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 p
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
>
[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 t
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 cha
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
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
[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).
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 inc
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 literal
[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,
>>
[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
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.
[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 ch
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
[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 probl
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,
>
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 c
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
> > understan
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 proble
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
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 wo
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* b
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 t
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 no
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 topi
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, natu
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.
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
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 in
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
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 th
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 t
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 insp
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
> > imple
[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 fun
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
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 F
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:
>>
77 matches
Mail list logo
