[Tim]
>> We could use the "I" (capital letter eye) length modifier under VC7.1.
>> That's good for both size_t and ptrdiff_t formats under VC7.1, where
>> ptrdiff_t under VC7.1 is really the same concept as Py_ssize_t.
[Martin]
> ptrdiff_t has the advantage of being available on all platforms,
>
[Shane Hathaway]
> What is the time frame for Python 2.5? If I finish soon and the changes
> are not disruptive, do I have enough time for my changes to make it into
> 2.5?
Yup! 2.5 hasn't even had an alpha release yet, and I don't expect
2.5a1 before March:
http://mail.python.org/pipermail
[Martin v. Löwis]
> ...
> I am talking about the entirety of these functions,
> and claim that they are rarely used (including the
> Unicode and buffer APIs).
This reminded me that I still owe you a reply about s# and t# format
codes. It occurred to me that I've never used them, and probably
neve
[David Goodger]
...
> An alternative is to use svn:externals to link to a specific
> revision (via the -r option);
Yes. please. svn:externals should always pin to a specific revision
(or at least to a "frozen" tag). Updating to a new revision then is
just a propedit away (to change the revision
[Tim Peters]
>> Yes. please. svn:externals should always pin to a specific revision
>> (or at least to a "frozen" tag). Updating to a new revision then is
>> just a propedit away (to change the revision number); ditto for
>> backing off to an older revi
[Christian Tismer]
> Hi Python developers,
>
> today I got a complaint from the python.de IRC channel
> about os.path.getmtime and time zone.
>
> How to produce the weird behavior:
>
> 1. create a file
> 2. get it's os.path.getmtime()
> 3. change your time zone
> 4. get os.path.getmtime again
>
> c
[Georg Brandl -- or so he claimed on January 8]
> today, when two Python developers here had approached me about the PSF, I
> realized that it is time to correct a mistake which I had made over three
> years
> ago, when I discovered Linux, free software, Usenet etc (I was sixteen at
> that time).
[vinay]
>> Log:
>> Fixed bug in time-to-midnight calculation.
[Skip]
> Is there some reason not to use datetime to do this?
PEP 291 says logging intends to be compatible with Python 1.5.2, which
leaves datetime out.
Vinay, rather than:
if (currentMinute == 0) and (currentSecond == 0):
[martin.v.loewis <[EMAIL PROTECTED]>]
> Date: Wed Jan 18 10:13:51 2006
> New Revision: 42090
>
> Added:
>python/trunk/PCbuild/make_buildinfo.vcproj
> Modified:
>python/trunk/Modules/getbuildinfo.c
>python/trunk/PCbuild/pcbuild.sln
>python/trunk/PCbuild/pythoncore.vcproj
> Log:
> Gen
[Tim]
>> Did this checkin perhaps forget to add that file?
[Martin]
> Oops, indeed - please try again.
It may ;-) be better now. Looks like the release build finished, but
the debug build died:
"""
-- Build started: Project: pythoncore, Configuration: Debug Win32 --
generate buildinfo
[Nick Coghlan]
> ...
> I quite like the suggestion of using 'math.base' rather than a builtin, but
> there are still issues to be figured out there:
>- the math module is currently a thin wrapper around C's "math.h". Do we
> really want to change that by adding more methods?
That's not an issu
[Gabriel Becedillas]
> Can anybody tell me if the patch I suggested is ok ?
> That will be to add the following code at the end of PyThreadState_Delete:
>
> if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
> PyThread_delete_key_value(autoTLSkey);
It needs a little work, but I t
[Tim]
>> ...
>> As a result, it so happens that core Python never uses the original
>> PyThreadState_Delete() anymore, except when Py_NewInterpreter() has
>> to throw away the brand new thread state it created because it turns out
>> it can't create a new interpreter.
[Michael]
> Um, PyThreadState
[Aahz]
>> Aside to Georg: your messages are all getting /dev/null'd because you use
>> "spam" in your From: line. I get too much spam to change that, and I'll
>> bet other people use that heuristic. Please change your From: line for
>> this mailing list.
[Georg Brandl]
> I don't quite understand
Has anyone else noticed this? For a long time (possibly years), I see
an infrequent error in test_socket_ssl, like so (this is on WinXP
Pro):
test_socket_ssl
test test_socket_ssl crashed -- exceptions.TypeError: 'NoneType'
object is not callable
I haven't been able to provoke it by running test_
[Tim Peters]
> ...
> test_rude_shutdown() is dicey, relying on a sleep() instead of proper
> synchronization to make it probable that the `listener` thread goes
> away before the main thread tries to connect, but while that race may
> account for bogus TestFailed deaths, it doesn&
[neal.norwitz]
> Modified:
>python/trunk/Lib/test/test_socket_ssl.py
> Log:
> There was a race condition where the connector would try to connect
> before the listener was ready (on gentoo x86 buildslave). This
> caused the listener to not exit normally since nobody connected to it
> (waited i
[Neal Norwitz]
> That's what I was thinking of. I thought you had to be accept()ing
> prior to connect() working. I thought listen() only sets the # of
> outstanding connections allowed (basically internal buffer). But if
> the listen() is sufficient, I agree there is no race.
listen() "should
[Thomas Wouters]
> ...
> I'd need developer access back to check it in, though.
AFAICT, twouters has developer access to the Python project --
although maybe someone else re-enabled that w/o mentioning it here.
> Unless anyone objects, of course :)
Of course I object! I bow to the group will, t
[Steve Holden]
> Is there any way to affect the target of the very prominent "Download
> Python" link on
> http://sourceforge.net/projects/python/ ?
>
> I ask because the link currently takes you to a page whose title is
> "Exiting with Error" and whose content is largely "No File Packages".
> Whil
[Thomas]
>>> I'd need developer access back to check it in, though.
[Tim]
>> AFAICT, twouters has developer access to the Python project --
>> although maybe someone else re-enabled that w/o mentioning it here.
[Thomas]
> I meant svn-checkin-access (it got disabled for disuse a while back.)
I kn
I suppose another possibility for why twouters couldn't check in is
because someone added him to the project's cvs_acls script. If so, I
don't know anything about how to get that changed.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
[Tim]
...
> AFAICT, you (twouters) already have it. There's a "Yes" in
> the twouters row under the "CVS Access" column on the Python project's
> Members admin page. Have you tried checking in? What happens when
> you do? ...
LOL -- what a bubblehead I am! Whether you can check in has nothing
[Martin v. Löwis]
> ...
> Also, I firmly believe that the FSF would *not* sue the PSF, but
> instead first ask that the status is corrected.
I'd say that's almost certain. Like any organization with something
fuzzy to protect, the FSF has far more to lose than to gain by daring
a court to rule on
[Stephen J. Turnbull]
> ...
> Aladdin took a position similar to Martin's, and only yanked the
> offending Makefile stanza when the FSF called them and said "we're
> ready to go to court; are you?"
> ...
> It's not theoretical; it's almost identical to the Aladdin case.
> Legally the PSF is, if a
[Guido van Rossum]
> It looks like the syntax for "from __future__ import ..." changes in
> Python 2.5. I was playing around with Cheetah, and it stumbled over a
> file with the following structure:
>
> # comments
> """ docstring """
> __author__ = "..."
> __version__ = "..."
> from __fu
[Thomas Wouters]
> I noticed a few compiler warnings, when I compile Python on my amd64 with
> gcc 4.0.3:
>
> Objects/longobject.c: In function 'PyLong_AsDouble':
> Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
> function
Well, that's pretty bizarre. There's _obviously
[Tim]
>> Well, that's pretty bizarre. There's _obviously_ no way to get to a
>> reference to `e` without going through
>>
>> x = _PyLong_AsScaledDouble(vv, &e);
>>
>> first. That isn't a useful warning.
[Guido]
> But how can the compiler know that it is an output-only argument?
In the a
[Martin v. Löwis]
> It inlines the function to make this determination.
Very cool! Is this a new(ish) behavior?
> Now, it's not true that e can be uninitialized then, but there
> the gcc logic fails:
That's fine -- there are any number of ways a compiler can reach a
wrong conclusion by making c
[Thomas Wouters]
> Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3
> (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
> behaves the same way. The normal make process shows quite a lot of output on
> systems that use gcc, so I wouldn't be surpri
[Thomas]
> Done,
Thanks!
> although it was nowhere near obvious to me that -1 would be a sane
> sentinel value ;) Not that I don't believe you, but it took some actual
> reading of _PyLong_AsScaledDouble to confirm it.
Nope, the thing to do was to read the docs for _PyLong_AsScaledDouble,
which
[Guido]
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
Huh! Was someone b
[Crutcher Dunnavant[
> Which reminds me, we need to support roman numeral constants.
One of my more-normal relatives reminded me that this is Super Bowl XL
Sunday, so your demand is more topical than it would ordinarily be.
Alas, there's already a PEP on this, and it was already rejected. See
PE
[Josiah Carlson]
> ...
> Back to the topic that Guido was really complaining about: Zope +
> asyncore. I don't doubt that getting Zope to play nicely with asyncore
> was difficult,
It's more that mixing asyncore with threads is a bloody nightmare, and
ZEO and Zope both do that. Zope (but not ZEO
[Raymond Hettinger]
> ...
> The asymmetric handling of denormals by the atof() and ftoa() functions is
> why you see a difference. A consequence of that asymmetry is the breakdown
> of the expected eval(repr(f))==f invariant:
Just noting that such behavior is a violation of the 754 standard for
s
Noticed that various socket tests are failing today, WinXP, Python trunk:
test_socket_ssl
Exception in thread Thread-27:
Traceback (most recent call last):
File "C:\Code\python\lib\threading.py", line 444, in __bootstrap
self.run()
File "C:\Code\python\lib\threading.py", line 424, in run
[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
[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
[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
[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,
>>
[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).
[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
[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]
>> 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
[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,
[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
[Martin v. Löwis]
> For the moment, I have committed Tim's original proposal.
Thank you! I checked, and that fixed all the test failures I was
seeing on Windows.
> Moving the macro into pyport.h could be done in addition. That
> should be done only if selectmodule is also adjusted; this currentl
[Tim]
>> The code in selectmodule when _MSC_VER is _not_ defined complains if a
>> socket fd is >= FD_SETSIZE _or_ is < 0. But the new code in
>> socketmodule on non-Windows boxes is happy with negative fds, saying
>> "fine" whenever fd < FD_SETSIZE. Is that right or wrong?
[Martin]
> I think it
1001 - 1049 of 1049 matches
Mail list logo
