Hello,
I have come across a situation where I find the current weak
references interface for extension types insufficient.
Currently you only have a tp_weaklistoffset slot, pointing to a
PyObject with weak references. However, in my case[1] I _really_ need
to be notified when a weak refere
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> You didn't show us what's in the zip file. Can you show a zipinfo output?
$ zipinfo modules.zip
Archive: modules.zip 426 bytes 2 files
-rw-r--r-- 2.3 unx 109 bx defN 31-Oct-05 14:49 module_o.pyo
-rw-r--r-- 2.3 unx 109 bx d
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
Unless others are interested in this nothing will happen.
I've never heard of a third party making their code available only as
.pyo, s
Gustavo J. A. M. Carneiro wrote:
> Hello,
>
> I have come across a situation where I find the current weak
> references interface for extension types insufficient.
>
> Currently you only have a tp_weaklistoffset slot, pointing to a
> PyObject with weak references. However, in my case[1] I
Qua, 2005-11-09 às 11:50 -0500, Jim Fulton escreveu:
> Gustavo J. A. M. Carneiro wrote:
> > Hello,
> >
> > I have come across a situation where I find the current weak
> > references interface for extension types insufficient.
> >
> > Currently you only have a tp_weaklistoffset slot, pointi
> > Gustavo J. A. M. Carneiro wrote:
> > > I have come across a situation where I find the current weak
> > > references interface for extension types insufficient.
> > >
> > > Currently you only have a tp_weaklistoffset slot, pointing to a
> > > PyObject with weak references. However, in my c
> Maybe it makes more sense to deprecate .pyo altogether and instead
> have a post-load optimizer optimize .pyc files according to the
> current optimization settings?
That would not be enough, because it would leave the docstrings in the .pyc
files.
> Unless others are interested in this nothin
Qua, 2005-11-09 às 09:23 -0800, Guido van Rossum escreveu:
> > > Gustavo J. A. M. Carneiro wrote:
> > > > I have come across a situation where I find the current weak
> > > > references interface for extension types insufficient.
> > > >
> > > > Currently you only have a tp_weaklistoffset slot,
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Maybe it makes more sense to deprecate .pyo altogether and instead
> have a post-load optimizer optimize .pyc files according to the
> current optimization settings?
I agree with this idea, but we've to think about docstrings (like
Nicola s
On 11/9/05, Osvaldo Santana <[EMAIL PROTECTED]> wrote:
> I've noticed this inconsistency when we stop to use zipimport in our
> Python For Maemo distribution. We've decided to stop using zipimport
> because the device (Nokia 770) uses a compressed filesystem.
I won't comment further on the brainst
On 9-nov-2005, at 18:52, Gustavo J. A. M. Carneiro wrote:
> Qua, 2005-11-09 às 09:23 -0800, Guido van Rossum escreveu:
Gustavo J. A. M. Carneiro wrote:
> I have come across a situation where I find the current weak
> references interface for extension types insufficient.
>
At 11:32 AM 11/9/2005 -0800, Guido van Rossum wrote:
>On 11/9/05, Osvaldo Santana <[EMAIL PROTECTED]> wrote:
> > I've noticed this inconsistency when we stop to use zipimport in our
> > Python For Maemo distribution. We've decided to stop using zipimport
> > because the device (Nokia 770) uses a co
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/9/05, Osvaldo Santana <[EMAIL PROTECTED]> wrote:
> > I've noticed this inconsistency when we stop to use zipimport in our
> > Python For Maemo distribution. We've decided to stop using zipimport
> > because the device (Nokia 770) uses
It's a shame that
1) there's no equivalent of "java -jar", i.e., "python -z FILE.ZIP", and
2) the use of zipfiles is so poorly documented.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
> It's a shame that
>
> 1) there's no equivalent of "java -jar", i.e., "python -z
> FILE.ZIP", and
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
-bob
_
Bob Ippolito <[EMAIL PROTECTED]> writes:
> On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
>
>> It's a shame that
>>
>> 1) there's no equivalent of "java -jar", i.e., "python -z
>> FILE.ZIP", and
>
> This should work on a few platforms:
> env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote:
> Bob Ippolito <[EMAIL PROTECTED]> writes:
>
>> On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
>>
>>> It's a shame that
>>>
>>> 1) there's no equivalent of "java -jar", i.e., "python -z
>>> FILE.ZIP", and
>>
>> This should work on a few platforms
Bob Ippolito wrote:
> On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
>
>> It's a shame that
>>
>> 1) there's no equivalent of "java -jar", i.e., "python -z
>> FILE.ZIP", and
>
> This should work on a few platforms:
> env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
Really? I wrote th
On Wed, 2005-11-09 at 20:40 +0100, Ronald Oussoren wrote:
> On 9-nov-2005, at 18:52, Gustavo J. A. M. Carneiro wrote:
>
> > Qua, 2005-11-09 às 09:23 -0800, Guido van Rossum escreveu:
> Gustavo J. A. M. Carneiro wrote:
> > I have come across a situation where I find the current weak
> >>
On 11/9/05, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote:
>
> > Bob Ippolito <[EMAIL PROTECTED]> writes:
> >
> >> On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
> >>
> >>> It's a shame that
> >>>
> >>> 1) there's no equivalent of "java -jar", i.e., "
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Maybe it makes more sense to deprecate .pyo altogether and instead
> have a post-load optimizer optimize .pyc files according to the
> current optimization settings?
>
But I thought part of the point of .pyo files was that they left out
doc
On Nov 9, 2005, at 6:05 PM, Brett Cannon wrote:
> I would have no issue with removing .pyo files and have .pyc files
> just be as optimized as they the current settings are and leave it at
> that. Could have some metadata listing what optimizations occurred,
> but do we really need to have a s
On 11/9/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Maybe it makes more sense to deprecate .pyo altogether and instead
> > have a post-load optimizer optimize .pyc files according to the
> > current optimization settings?
>
> But I thoug
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/9/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Plus I wouldn't be
> > surprised if we started to move away from bytecode optimization and
> > instead tried to do more AST transformations which would remove
> > possible post-load opt
At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote:
>The only solutions I can think of that use a single file actually
>*increase* the file size by having unoptimized and optimized code
>side-by-side, or some way to quickly skip the assertions -- the -OO
>option is a special case that probably nee
On 11/9/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote:
> >The only solutions I can think of that use a single file actually
> >*increase* the file size by having unoptimized and optimized code
> >side-by-side, or some way to quickly skip the ass
[Guido]
> > However, this would be a major pain for the standard library and other
> > shared code -- there it's really nice to have a cache for each of the
> > optimization levels since usually regular users can't write the
> > .py[co] files there, meaning very slow always-recompilation if the
> >
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > However, this would be a major pain for the standard library and other
> > > shared code -- there it's really nice to have a cache for each of the
> > > optimization levels since usually regular users can't write the
> > > .py[
Gustavo J. A. M. Carneiro wrote:
> OK, but what if it is a subclass of a builtin type, with instance
> variables? What if the PyObject is GC'ed but the ObjC object remains
> alive, and later you get a new reference to it? Do you create a new
> PyObject wrapper for it? What happened to the ins
> > I like Phillip's suggestion -- no new opcode, just a conditional jump
> > that can be easily optimized out.
>
> Huh? But Phillip is suggesting a new opcode that is essentially the
> same as my proposal but naming it differently and saying the bytecode
> should get changed directly instead of h
Martin v. Löwis wrote:
> Michiel Jan Laurens de Hoon wrote:
>
>> 2) Will Tkinter always be the standard toolkit for Python, or are
>> there plans to replace it at some point?
>
>
> Python does not evolve along a grand master plan. Instead, individual
> contributors propose specific modifications,
On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I like Phillip's suggestion -- no new opcode, just a conditional jump
> > > that can be easily optimized out.
> >
> > Huh? But Phillip is suggesting a new opcode that is essentially the
> > same as my proposal but naming it differently
On 11/9/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > I like Phillip's suggestion -- no new opcode, just a conditional jump
> > > > that can be easily optimized out.
> > >
> > > Huh? But Phillip is suggesting a new opcode that is esse
Tim Peters wrote:
> ...
> Someone want a finite project that would _really_ help their Uncle
> Timmy in his slow-motion crusade to get Python on the list of "solved
> it!" languages for each problem on that magnificent site?
...
> Turns out it's _not_ input speed that's the problem here, and not ev
Michiel Jan Laurens de Hoon wrote:
> At this point, I can't propose a specific modification yet because I
> don't know the reasoning that went behind the original choice of Tk as
> the default GUI toolkit for Python
Probably because at the time it was really the
only cross-platform GUI toolkit
On Thu, 10 Nov 2005 16:02:04 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>> At this point, I can't propose a specific modification yet because I
>> don't know the reasoning that went behind the original choice of Tk as
>> the default GUI toolkit for Python
>
>
> This should work on a few platforms:
> env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
Yeah, that's not bad, but I hate setting PYTHONPATH. I was thinking
more along the line of
python -z ZIPFILE
where python would look at the ZIPFILE to see if there's a top-level
module called "__
Excuse my English
I think, we could just segregate tokens for decimal and real float and
make them interoperable.
Motivation:
Most of us works with business databases - all "floats" are really
decimals, algebraic operations
should work without float inconsistency and those operations rare so
I just finished fleshing out the dev FAQ
(http://www.python.org/dev/devfaq.html) with questions covering what
someone might need to know for regular usage. If anyone thinks I
didn't cover something I should have, let me know.
-Brett
___
Python-Dev maili
> "Michiel" == Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> writes:
Michiel> What is the advantage of Tk in comparison to other GUI
Michiel> toolkits?
IMO, Tk's _advantage_ is that it's there already. As a standard
component, it works well for typical simple GUI applications (thus
Greg Ewing wrote:
>I'm not sure the event-loop situation would be
>much different with another one, anyway. From what
>I've seen of GUI toolkits, they all have their own
>form of event loop, and they all provide some way
>of hooking other things into it (as does Tkinter),
>but whichever one you're
Stephen J. Turnbull wrote:
>Michiel> What is the advantage of Tk in comparison to other GUI
>Michiel> toolkits?
>
>IMO, Tk's _advantage_ is that it's there already. As a standard
>component, it works well for typical simple GUI applications (thus
>satisfying "batteries included" IMO), and
On 9-nov-2005, at 23:44, Gustavo J. A. M. Carneiro wrote:
> On Wed, 2005-11-09 at 20:40 +0100, Ronald Oussoren wrote:
>> On 9-nov-2005, at 18:52, Gustavo J. A. M. Carneiro wrote:
>>
>>> Qua, 2005-11-09 às 09:23 -0800, Guido van Rossum escreveu:
>> Gustavo J. A. M. Carneiro wrote:
>>> I
Gustavo J. A. M. Carneiro wrote:
> OK, but what if it is a subclass of a builtin type, with instance
> variables? What if the PyObject is GC'ed but the ObjC object remains
> alive, and later you get a new reference to it? Do you create a new
> PyObject wrapper for it? What happened to the inst
Michiel Jan Laurens de Hoon wrote:
> At this point, I can't propose a specific modification yet because I
> don't know the reasoning that went behind the original choice of Tk as
> the default GUI toolkit for Python (and hence, I don't know if those
> reasons are still valid today).
I don't kno
Well, wouldn't you know it.
I get the code right and mess up the directions.
Scott David Daniels wrote:
> if you build this module, I'd suggest using
> "from to_int import chomp" to get a function that works like int
> (producing a long when needed and so on).
Well, actually it is a bit more tha
Michiel Jan Laurens de Hoon wrote:
> It's not because it likes to be in charge, it's because there's no other
> way to do it in Python.
As I said: this is simply not true.
> Tkinter is a special case among GUI toolkits because it is married to
> Tcl. It doesn't just need to handle its GUI event
47 matches
Mail list logo
