for sizes above
215, pools need to be spaced apart only at 16 bytes.
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
the whole point of the PEP. Or are you asking why the user
shouldn't be allowed to pass keyword-only arguments by omitting the
keyword? Because they wouldn't be keyword-only arguments then, anymore.
Regards,
Martin
___
Python-Dev mailing list
Pyth
t algorithms that currently operate
on byte strings should be reformulated to operate on character strings,
not reformulated to operate on bytes objects.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
d "just work", and
b) people will refuse to rewrite their algorithms for character
strings (which they likely should in most applications of,
say, .startswith), and then complain that the bytes type
is s limited, and they really want a full byte string
type back.
Regards
certainly need a "concatenate list of bytes into a single
bytes". Apparently, Guido assumes that this can be done through
bytes().join(...); I personally feel that this is over-generalization:
if the only practical application of .join is the empty bytes
object as separator, I thin
sible for collecting all feedback, and either updating
the specification, or at least, summarizing the discussion and the
open issues (so that the same argument isn't made over and over again).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@p
rs because Tk fails to unlock a mutex
in a few error cases. The patch below fixes the problem.
I'll report it to the Tcl people, and see whether I can work around
in _tkinter.
Regards,
Martin
diff -ur tk8.4.13/generic/tkWindow.c tk8.4.13.modified/generic/tkWindow.c
--- tk8.4.13/generic/tkWind
le. Use the string type instead.
> So, what to do? Rename Python 2.x str to bytes. The name of the type
> now confers the idea that it should contain bytes, not strings.
It seems that you want an immutable version of the bytes type. As I
don't understand what "parsing" is, I can
name?
I see an important use case for k=0 functions, and k=1 methods (where
the only positional argument is self).
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
Terry Reedy wrote:
>>>> Now, suppose you wanted to have 'key' be a keyword-only argument.
>>> Why? Why not let the user type the additional argument(s) without the
>>> parameter name?
>
> Like Martin, you clipped most of the essential context
pe someone with Tkinter knowledge can step in and fix it.
> (It looks like SF auto-assigned it to Martin already, hmm.)
I have now reported the underlying Tk bug at
http://sourceforge.net/tracker/index.php?func=detail&aid=1479587&group_id=12997&a
Josiah Carlson wrote:
> Certainly that is the case. But how would you propose embedded bytes
> data be represented? (I talk more extensively about this particular
> issue later).
Can't answer: I don't know what "embedded bytes data" are.
> Um...struct.unpack() already works on unicode...
> >
Edward Loper wrote:
> Martin v. Löwis wrote:
>> One reason I see is to have keyword-only functions, i.e. with no
>> positional arguments at all:
>>
>> def make_person(*, name, age, phone, location):
>> pass
>
> But is it necessary to syntactically *e
e case for bare * that
> does make sense to me.
It's actually the same use case: I don't *want* callers to pass these
parameters positionally, to improve readability.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
mitted, we can only hope for (other)
volunteers to provide the documentation, or keep nagging the author
of the code to produce it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
clause
SF patch 102989 by Thomas Wouters
----
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
27;finally' clause: What would that mean?
Given
def f():
raise Exception
while 1:
try:
f()
finally:
g()
continue
then what should be the meaning of "continue" here? The finally
block *eventually* needs to re-raise the excepti
ry
> data. It was also supposed to show how one may need to define symbols
> for such interpretation via literals of some kind. In the pickle module,
> this is done in two parts: XXX = ; dispatch[XXX] = fcn. I've
> also seen it as dispatch = {: fcn}
Yes. For pickle, the o
precated,
> and documented in terms of repr (rather than the other way around) ?
I vaguely recall that they are deprecated, but I can't remember the
details. The one obvious way to invoke that functionality is the repr()
builtin.
Regards,
Martin
, requiring patches to #define
> HAVE_DIRECT_H for other platforms
That would be best. Python generally uses autoconf methodology, which
implies that conditionally-existing headers should be detected using
HAVE_*_H.
Regards,
Martin
___
Python
Fredrik Lundh wrote:
> I'm +1 on adding --help and --version, +1 on adding -? and /? for windows
> only,
> -0=slightly sceptical if adding a generic long option machinery is worth it,
> and -1
> on a guessing machinery.
I also agree with all these judgmen
to track the status of the individual projects,
and either revoke commit privs when the project is eventually
completed, or grant the contributors permanent (without-approval)
commit privs if he considers this appropriate.
Regards,
Martin
___
Python
orce it - but I'm sure sprint participants
would restrict checkins to a branch if they were told to.
However, I don't see how that would help.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
ubversion) to set up a sprint area in
> the repo.
It works fine for http(s), but not for svn+ssh.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
Luke Dunstan wrote:
> OK. Actually I think distutils will be the last thing to be ported because
> it is not necessary for using the rest of Python. Does distutils has support
> for cross-compiling anyway?
No, it doesn't.
> OK, but what about ANSI C headers like signal.h? I expected HAVE_SIGNAL
would that work? Apache is not involved at all.
> Subversion 1.3 added a path-based authorization feature to svnserve.
That's what I mean by "does not work fine": I would need to update
to subversion 1.3.
Regards,
Martin
___
Python-Dev m
arises at creation of the list of timers.
For a list of timers/timeout events, a priority queue is often the best
data structure, which is already available through the heapq module.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
h
ode file names in a reasonable way anymore.
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
branches.
Just to not be mistaken: it is technically fairly easy to add somebody
to the committers list. So technical, there is no problem to add all
sprinters.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
in place would also ease
> fears that sprint output might be "subverted" to non-open status.
That would be desirable, indeed. It shouldn't be too difficult to
collect the forms "on site".
Regards,
Martin
___
Python-Dev
Tim Peters wrote:
> [Martin v. Löwis]
>> I completely agree. Just make sure you master the mechanics of adding
>> committers.
>
> So there's a practical problem: is that procedure documented
> somewhere?
I once posted the procedure to all current pydotorg project a
pt that anybody doing the merge-back
would have to come up with sensible commit messages, and (ideally)
sensible attributions.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
t; more fine-grained Win32 error code.
Ok. I'll try to come up with a patch, but let me repeat
this: even though this would nearly restore the behavior
for the functions that I changed, it would *a different*
incompatible change, since it would change t
specific Win32 error codes, just because they are
more descriptive. I propose to call the module "winerror"
(in parallel to winerror.h, just as the errno module
parallels errno.h)
Adding them all to the errno would work for most cases,
except that you get conflict
Neal Norwitz wrote:
> Martin: msilib -- Martin/Andrew is this done?
That's done, yes.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
2.4.4 is likely to occur *after* the release of 2.5.0.
Not sure when Apple decides to freeze the Python version for the next
OS release, but if they really chose the most recent one "by policy",
that will be either 2.5.0 or 2.4.3.
Regards,
Martin
__
r should grow a flag
indicating whether you want to clear just all Exceptions, or
indeed all BaseExceptions.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
effects), the entire idea should be dropped (IMO). OTOH, I don't
find such a size increase unacceptable myself.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
, for a total of 20 bytes
at run-time.
On a 64-bit machine, the strings should consume 101128 bytes (***),
the integers 24160, and the dict entries 20 bytes,
for a total of 325000 bytes.
>From that, I would conclude that one should avoid 64-bit machines
if one is worried about memor
it signed. If unsigned printing of size_t
is desired, %zu should be used.
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
Georg Brandl wrote:
> Similary, there's no way for a structmember to be of type Py_ssize_t...
Right. At least, not with changing structmember.[ch].
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Somebody has contributed an edited version of the current icons,
at
https://sourceforge.net/tracker/index.php?func=detail&aid=1481304&group_id=5470&atid=305470
He claims that his version is prettier in small sizes; I'm
uncertain whether this is the case.
What do you think?
. So if it is desired, it needs to
be added first, and then should be used.
Looking at the checkin messages, I understand that the change from "d"
to "u" was to make some compiler stop warning - that is the wrong
motivation for such a behavioral change.
Regards,
Martin
___
types supported.
I wonder what the specific application is that you have in mind,
though.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
are indeed created twice, something is wrong.
> I agree that creating only one dictionary statically
> and the other mapping dynamically will already be a
> saving of 50% simply by sharing the string and integer
> objects.
No, they should be shared already, so that shou
ems; that seems
like a waste of resources to me, though. One should also reset
import_lock_thread and import_lock_level.
I'd be curious if Elemental Security added this code only to solve
the very same problem, i.e. a fork that happened with the import
lock held.
Regards,
Martin
__
additional autoconf tests in 46010 and 46011;
unfortunately, I cannot test these changes as I don't have a system
where the build was broken.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
course, like the __import__ builtin)
So if you are certain that the fork doesn't happen *while* an import
is going, then I think the specific problem must be analyzed in more
detail before an attempt is made to fix it.
Regards,
Martin
___
Python-Dev
tside execve, you have only hidden the problem, instead of
solving 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
should find a repeatable test case first.
Contributions are welcome.
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/a
't quite understand
the test case given, and I can't make it deadlock anymore (probably
because of Just's fix).
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
rary will first acquire the import lock in the thread
that wants to fork. Then the fork occurs, and the import lock gets
then released both in the parent and in the child.
I would like to see this approach implemented, but I agree with you
that a test case should be created
dified (i.e. fork1, and forkpty also).
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
.c. I wonder why the
> last gcc line above has "-lz" in it?
By convention, the Unix build doesn't use the included zlib. Unix users
typically insist on using the system libraries when they are available,
so nobody has even contributed a build procedure to use
b if the system zlib
is too old
drawback: you get all the problems of static linking, e.g.
the size increase, and the problems with two zlib versions
living in the same address space for some embedded Python
applications
I'm not volunteering to implement any of the options.
Re
apshot (and then close the zlib stream).
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
should be on that system.
Of course, it would be fairly straight-forward to convert this
to standard autoconf machinery (if one remembers to update
PC/pyconfig.h accordingly). I'm sure Luke Dunstan would be willing
to revise the patch in that dire
ould get dropped entirely. I'm not
available for creating installers in the following week, so the earliest
day to make alpha 3 would then be June 5, but traditionally, it would
be June 8.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
fixes.
Likewise, if you don't think you can fix them, don't bother - some
user of the platform will provide the missing pieces.
Or, if no contributions from a user arrive, it either means that
it just works fine, or that there are no users.
Regards,
Martin
__
will PyInt_AsLong do? What about systems where "long long"
is not supported?
Not that those can't be resolved (they were resolved, in some way or
the other, for ssize_t). However, I think a complete specification of
the proposed c
horrible.
py> +"Hello"
Traceback (most recent call last):
File "", line 1, in ?
TypeError: bad operand type for unary +
py> +1*"Hello"
'Hello'
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Ronald Oussoren wrote:
> I don't know which one Fredrik thinks is wrong, but I think the result
> of -1*(1,2,3) is very surprising. I'd expect an exception here.
I agree, but this has nothing to do with whether or not the unary -
is supported.
s ever supported, I think it should also go
into the select module.
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%
ot; is really quite involved. We cannot just incorporate the
code without permission of the author. So if the code is itself
acceptable, then somebody would have to talk the author into
contributing.
Regards,
Martin
___
Python-Dev mailing lis
nchat, although people don't like it. I'm sure
the Twisted people would integrate epoll in no time, and with
no API change for *their* users.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
iting for ENOSYS from epoll_create is probably cheap enough).
Also, it would be good if the application could find out it is using
epoll; for example, epollObject could expose a fileno member.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
of constants is propably fine.
I would just provide a second constructor, select.epoll(),
which guarantees that epoll is used as the implementation
strategy (i.e. it would raise OSError if the kernel doesn't
support epoll_create).
Regards,
Martin
don't care
(providing the flag might be actually more expressive, since it would
also allow to specify "I want poll", although I can't see a use case
for that).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
I would accept it providing it was disabled on
OSX (assuming kqueue really is not true poll replacement on this
system).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
what would you store in the additional data?
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
n that case, the directory
itself would have been imported, not the thing inside. The warning
is (also) a hint that you should do some renaming - future versions
of Python might drop the need for __init__.
Regards,
Martin
___
Python-Dev mailing list
ctionality very awkward.
>
> Rather than adding yet another platform-dependent module,
> I'd like to see a unified Python interface in the stdlib
> that uses whichever is the best one available.
For epoll, that interface seems to
her file descriptor 0 is ready, I would assume
that select is even better.
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
get back the PyObject pointer so can't decrement
> the refcount, has to be stored and looked up manually.
Ah. That would be an interface change; I would not do that. The lookup
is usually-constant and very fast. It is complexity that grows with the
number of file descriptors that these APIs
wo cents"
and "experience" roughly the same thing, so that one is redundant?)
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
converted.
I think that should be done for 2.5, but nothing else. Or, perhaps
a deprecation warning could be generated if it is still used.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
at all in the method structures.
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
out of scope for 2.5. Guido said it is ok
to change this to 64-bit ints in 2.6, but I expect some embedded
system developers will start screaming when they hear that: 64-bit
arithmetic is expensive on a 32-bit machine.
Regards,
Martin
___
Python-Dev mailing
s for the regexes
themselves (e.g. size of the compiled expression, number of repeats,
etc).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
It would still be a large change,
and should be only done if we know for sure we don't want it to be
a 64-bit type always the next day.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Georg Brandl wrote:
> I thought more about PyArg_Parse for __deprecated__.
Ah, PyArg_Parse can, of course. Having it actually do that should not
hurt, either - but you need a reliable check whether the compiler
supports __deprecated__.
Regards,
Mar
Guido van Rossum wrote:
>> I think that should be done for 2.5, but nothing else. Or, perhaps
>> a deprecation warning could be generated if it is still used.
>
> I'll let Martin decide this one.
I just sent a message to some that producing a DeprecationWarning is
fi
www.python.org/psf/contrib/ seem like the right page to link
> to?
That is the page giving instructions on how to fill it out, yes.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
eTuple "i" will continue to produce int, and
raise an exception (OverflowError?) when the value is out of range.
C code can then decide whether to parse a Python integer as
C int, long, long long, or ssize_t.
Regards,
Martin
___
P
type into a
dictionary. If the type is anonymous, they will do
dispatch[type(0)] = marshal_int
dispatch[type(sys.maxint+1)] = marshal_int
Plus, their current code as
dispatch[int] = marshal_int
which will silently break (although it won't be silent if they also
have dispatch[long] = marsha
t. If the module is unmaintained, producing a warning now
might not help, either.
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
ocess
> time
> on an equally loaded system.
On Linux, process time is accounted in jiffies. Unfortunately, for
compatibility, times(2) converts that to clock_t, losing precision.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyt
erted:
http://python.cvs.sourceforge.net/python/python/dist/src/Mac/IDE%20scripts/
These had caused ongoing problems for Windows, which could not stand
files with trailing dots.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
ython (this hasn't happened so far).
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
ts. on my machine, CLOCKS_PER_SEC is a
> thousand times larger than HZ. what does this code print on your machine?
You are right; clock_t allows for higher precision than jiffies.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.o
2/kernel.php3
>
> under "No more jiffies?":
[...]
>
> Maybe this varies by Linux flavor or version?
No, Fredrik is right: Linux samples process time, instead of measuring
it. That only proves it is not a modern operating system :-)
I would still h
To find out whether it samples or
measures CPU usage, you really have to read the source code of the
operating system (or find some documentation of somebody who has seen
the source code).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyt
Thomas Heller wrote:
> In Include/structmember.h, there is no T_... constant for Py_ssize_t
> member fields. Should there be one?
As Fredrik says: if you need it, feel free to add it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
Jim Jewett wrote:
> Martin v. Löwis replied:
>
>> ... column numbers shouldn't exceed 16-bits, and line #s
>> shouldn't exceed 31 bits.
>
> Why these particular numbers?
>
> As nearly as I can tell, 8 bits is already too many columns for human
>
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0] references
1 test OK.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
tion of
FILETIME *originates* from the way NTFS stores time stamps.
For FAT, the on-disk precision is worse, of course.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
nd and implement that. As this is all fairly non-trivial,
and must also consider a lot of prior art, it is unlikely that something
will be done about it in the next years.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
ernal libraries.
> Is it strictly forbidden to add new features in ctypes during the
> (Python) beta period?
I think it strictly requires explicit permission of the release manager.
If many people want more time, we should move the release schedule.
OTOH, there will always b
ny existing features - they still
don't get the testing that the beta releases try to achieve.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
that's part of core
> Python? It looks like the only Win32 API you use is CoCreateGUID, so
> wrapping it should be doable...
http://docs.python.org/dev/lib/module-msilib.html#l2h-5633
Regards,
Martin
___
Python-Dev mailing list
Python-De
5001 - 5100 of 5770 matches
Mail list logo
