Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
Nick Coghlan <[EMAIL PROTECTED]> writes: > Gareth McCaughan wrote: >> [Keith Dart:] >>>By "normal" integer I mean the mathematical definition. >> >> Then you aren't (to me) making sense. You were distinguishing >> this from a unified int/long. So far as I can see, a unified int/long >> type *does* implement (modulo implementation limits and bugs) >> the "mathematical definition". What am I missing? > > Hmm, a 'mod_int' type might be an interesting concept (i.e. a type > that performs integer arithmetic, only each operation is carried out > modulo some integer). > > Then particular bit sizes would be simple ints, modulo the appropriate > power of two. ctypes provides mutable platform integers and floats of various sizes (and much more). Currently they don't have any methods, only the value attribute. Maybe it would be useful to implement the standard numeric methods on them. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] is type a usable feature?
Hello developers,I noticed my application was growing strangely while I
was using type, then I tried this:
while True:
type('A',(),{})
and saw memory filling up.Is there a clean solution to that?
I see it as a bug in python engeneering,that is why I wrote to you.
Thanks a lot
Paolino
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is type a usable feature?
[Paolino <[EMAIL PROTECTED]>]
> Hello developers,I noticed my application was growing strangely while I
> was using type, then I tried this:
>
> while True:
> type('A',(),{})
>
> and saw memory filling up.Is there a clean solution to that?
> I see it as a bug in python engeneering,that is why I wrote to you.
Python bugs should be reported on SourceForge:
http://sourceforge.net/tracker/?group_id=5470&atid=105470
Please specify the Python version and OS. I do not see memory growth
running the above under Python 2.3.5 or 2.4.1 on Windows, so I don't
have any evidence of a bug here in the Pythons I usually use.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is type a usable feature?
Tim Peters wrote:
> [Paolino <[EMAIL PROTECTED]>]
>
>>Hello developers,I noticed my application was growing strangely while I
>>was using type, then I tried this:
>>
>>while True:
>> type('A',(),{})
>>
>>and saw memory filling up.Is there a clean solution to that?
>>I see it as a bug in python engeneering,that is why I wrote to you.
>
>
> Python bugs should be reported on SourceForge:
>
> http://sourceforge.net/tracker/?group_id=5470&atid=105470
>
> Please specify the Python version and OS. I do not see memory growth
> running the above under Python 2.3.5 or 2.4.1 on Windows, so I don't
> have any evidence of a bug here in the Pythons I usually use.
>
Sorry, the growth happens using ipython shell.With python original shell
there is nothing wrong.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is type a usable feature?
Tim Peters wrote:
> [Paolino <[EMAIL PROTECTED]>]
>
>>Hello developers,I noticed my application was growing strangely while I
>>was using type, then I tried this:
>>
>>while True:
>> type('A',(),{})
>>
>>and saw memory filling up.Is there a clean solution to that?
>>I see it as a bug in python engeneering,that is why I wrote to you.
>
>
> Python bugs should be reported on SourceForge:
>
> http://sourceforge.net/tracker/?group_id=5470&atid=105470
>
> Please specify the Python version and OS. I do not see memory growth
> running the above under Python 2.3.5 or 2.4.1 on Windows, so I don't
> have any evidence of a bug here in the Pythons I usually use.
>
Sorry, the growth happens using ipython shell.With python original shell
there is nothing wrong.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] refcounting vs PyModule_AddObject
[Michael Hudson]
>> I've been looking at this area partly to try and understand this bug:
>>
>> [ 1163563 ] Sub threads execute in restricted mode
>>
>> but I'm not sure the whole idea of multiple interpreters isn't
>> inherently doomed :-/
[Martin v. Löwis]
> That's what Tim asserts, saying that people who want to use the
> feature should fix it themselves.
I haven't said they're doomed, although I have said that people who
want to use them are on their own. I think the latter is simply an
obvious truth, since (a) multiple interpreters have been entirely
unexercised by the Python test suite ("if it's not tested, it's
broken" rules); (b) Python developers generally pay no attention to
them; and (c), as the teensy bit of docs for them imply, they're an
"80% solution", but to a problem that's probably more sensitive than
most to glitches in the other 20%.
I've also said that Mark's thread state PEP explicitly disavowed
responsibility for working nicely with multiple interpreters. I said
that only because that's what his PEP said .
___
Python-Dev mailing list
[email protected]
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 304 - is anyone really interested?
Skip Montanaro wrote: > I wrote PEP 304, "Controlling Generation of Bytecode Files": > > http://www.python.org/peps/pep-0304.html I would like to see some way of having bytecode files put into platform/version dependent subdirectories, which would make it easier e.g. to have Python code shared over a network between machines of different architectures or running different Python versions. But the scheme this PEP proposes (a single session-wide location) is too coarse-grained for what I have in mind. So I would not support this particular PEP without sufficiently large changes that it might as well become a new PEP. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] 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 304 - is anyone really interested?
On Jun 23, 2005, at 10:11 PM, Greg Ewing wrote: > Skip Montanaro wrote: > >> I wrote PEP 304, "Controlling Generation of Bytecode Files": >> >> http://www.python.org/peps/pep-0304.html >> > > I would like to see some way of having bytecode files put > into platform/version dependent subdirectories, which > would make it easier e.g. to have Python code shared > over a network between machines of different architectures > or running different Python versions. But the scheme this > PEP proposes (a single session-wide location) is too > coarse-grained for what I have in mind. So I would not > support this particular PEP without sufficiently large > changes that it might as well become a new PEP. You could implement that in your sitecustomize.py, unless you have Python interpreters that change platform or version mid-session. I don't see why it needs to be subdirectories, you could make the bytecode cache local or somewhere on the server that you have write access to. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
