Wow, thanks to both of you (Phillip & Skip) for the fast answers.
Just in case anyone has time to spare, I have more pesky questions (and a
working patch :-)) in the aforementioned bug entry
(http://bugs.python.org/issue2459).
Regards
Antoine.
___
Py
At 10:43 PM 3/22/2008 +, Antoine Pitrou wrote:
>- Why are there both relative and absolute jump instructions? The traditional
>rationale for relative jumps (apart from position-independent code)
>is to allow
>for shorter operand sizes; but Python opcodes all have the same operand size
Actuall
Antoine> - Why are there both relative and absolute jump instructions?
The best place to search for the reasons behind this is Python/compile.c.
(JUMP_ABSOLUTE can jump backwards.) There have been lots and lots of
changes to the Python virtual machine the past few years. When trying to
under
Hi,
I'm attempting some bytecode tweaks (see http://bugs.python.org/issue2459) and
I've got two questions about jump instructions:
- Why are there both relative and absolute jump instructions? The traditional
rationale for relative jumps (apart from position-independent code) is to allow
for shor
What is the current state of the N-D Array Interface proposal
(http://numpy.scipy.org/array_interface.shtml). Some work was done on
this in an earlier Summer of Code, but it seems to never have been
included. Does anybody know what state that work is in and what
prevented it's inclusion?
(I am int
On Sat, Mar 22, 2008 at 4:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > For the buildbots, it would be easy to turn -3 on, though.
> >
> > Should I work a patch to allow Python code to disable/enable the flag?
>
> +0.
See issue 2458.
>
>
> Regards,
> Martin
>
--
Cheers,
Benjami
> For the buildbots, it would be easy to turn -3 on, though.
>
> Should I work a patch to allow Python code to disable/enable the flag?
+0.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Sat, Mar 22, 2008 at 3:58 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> Steven Bethard wrote:
> > Right now, test_py3kwarn only runs if the test suite is run using the
> > -3 command line flag to Python. So for most regrtest runs (e.g. the
> > buildbots) this test will never be run.
>
> Fo
Guido van Rossum schrieb:
>> When the new buffer protocol is available in 2.6 we can start back
>> porting bytesarray and the new IO framework.
>
> Are these really so closely tied that they have to wait before they
> can be backported?
I've started with the backport of the bytearray type in a
Steven Bethard wrote:
> Right now, test_py3kwarn only runs if the test suite is run using the
> -3 command line flag to Python. So for most regrtest runs (e.g. the
> buildbots) this test will never be run.
For the buildbots, it would be easy to turn -3 on, though.
Regards,
Martin
> I think it can actually be simplified. I think maintaining binary
> compatibility between 2.6 and earlier versions is hopeless anyway
ABI-wise or API-wise?
I would surely hope that the 2.6 API is "mostly" compatible with the
2.5 API.
Regards,
Martin
On Sat, Mar 22, 2008 at 3:34 PM, Steven Bethard <[EMAIL PROTECTED]>
wrote:
> Right now, test_py3kwarn only runs if the test suite is run using the
> -3 command line flag to Python. So for most regrtest runs (e.g. the
> buildbots) this test will never be run.
>
> It would be nice to be able to tur
Right now, test_py3kwarn only runs if the test suite is run using the
-3 command line flag to Python. So for most regrtest runs (e.g. the
buildbots) this test will never be run.
It would be nice to be able to turn the flag on from Python (e.g.
within test_py3kwarn). Is that possible? Here's what
> I haven't been around during the 1.x -> 2.x days. I was still in the
> dark ages (aka PHP user).
:-)
> How do you want me to tackle down the PyString / PyBytes problem?
I think it can actually be simplified. I think maintaining binary
compatibility between 2.6 and earlier versions is hopele
>>> Oh, and application installation is (should be) completely different.
>> > On Windows, applications should probably be bundled with their own
>> > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
>> > standard is, so I'd have to defer to others.
>>
>>
>> This I disagree
On 22/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Oh, and application installation is (should be) completely different.
> > On Windows, applications should probably be bundled with their own
> > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
> > standard is,
I think this howto is of general interest to the community, but I'm
crossposting to Tracker-Discuss and redirecting discussion there.
Reply-To set.
Barry Warsaw writes:
> Thanks Martin, I think this will work for now. Is there any way you
> can allow me to edit this query too?
While as Mart
Guido van Rossum schrieb:
> Right. We've done this 2-stage rename before, during the great
> (sometimes known as grand) renaming, in the 1.x days.
I haven't been around during the 1.x -> 2.x days. I was still in the
dark ages (aka PHP user).
How do you want me to tackle down the PyString / PyByte
> If a test case is needed I can attach one later on.
You should put all this into bugs.python.org, preferably with
a patch implementing it also.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
> Oh, and application installation is (should be) completely different.
> On Windows, applications should probably be bundled with their own
> Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
> standard is, so I'd have to defer to others.
This I disagree with. I think it's an
>> Sure, but what is precisely the semantics of uninstallation, in
>> terms of changes to the system state?
>>
>> I think any model where uninstallation is merely the removal
>> of files is too limited to be practical.
>
> The distutils only support the *addition* of files, so I'm not sure
> how
> Huh? How's that? Don't forget that I'm on Windows, and on Windows
> there is no "system tool" - just bdist_wininst, bdist_msi and
> easy_install. The fact that bdist_wininst and bdist_msi link into the
> system UI for listing and uninstallation doesn't make packages using
> them "system packages"
Neal Becker wrote:
> Another use case, which I find in my world, is that there are always
> packages that interest me (found at pypi), that my vendor hasn't packaged
> as rpms yet.
>
> With finite resources, this will always be true.
Why do you need a package database for that? Can't you just run
> I more question the permissions and uid/gid stuff; I'm not really
> clear on what I'd use that stuff for in easy_install/uninstall/etc.
I think this was all captured in amk's statement "RPM-like
verification". RPM not only verifies file content, but also whether
the permissions are all correct.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 22, 2008, at 11:31 AM, Martin v. Löwis wrote:
>> Thanks Martin, I think this will work for now. Is there any way
>> you can allow me to edit this query too?
>
> Not easily.
>
> I could just remove it, and allow you to create a new one (or you
> In the case of Fedora rpms, the usual install uses setup.py.
Ok. Does it then also package all files that get installed into
the RPM file? If it produces multiple RPMs from a single source
package, how does it know which files go into what RPM?
Regards,
Martin
__
At 04:29 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>>For those without the read-only flag, the specification should
>>>explicitly say what manipulation is allowed.
>>Since a distribution isn't really "mutable", I would think that
>>uninstallation and reinstallation would be the only manipulation
On 22/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> This probably needs to be refined a little. Exclusive right is too
> strong, and it goes against Paul Moore's desire for using a single
> tool.
Huh? How's that? Don't forget that I'm on Windows, and on Windows
there is no "system tool"
> I speak for Debian, so for Debian: yes. The setup.py would have to be
> pretty bad for a packager to not use it. There is no reason to
> re-write upstream's installation procedure as you would have to figure
> out which files need to be installed where and this would create many
> bugs.
>
> Th
At 11:19 AM 3/22/2008 -0400, Phillip J. Eby wrote:
>Not exactly. More like, "package management tool X claims exclusive
>rights to this package". Python tools would always defer this right
>to the system packager, i.e. a system packager is not obliged to
>respect a Python tool's claim to a file,
> Thanks Martin, I think this will work for now. Is there any way you can
> allow me to edit this query too?
Not easily.
I could just remove it, and allow you to create a new one (or you create
one yourself, anyway, and I remove mine later).
Regards,
Martin
>> For those without the read-only flag, the specification should
>> explicitly say what manipulation is allowed.
>
> Since a distribution isn't really "mutable", I would think that
> uninstallation and reinstallation would be the only manipulation
> available. (As distinct from inspection, ver
At 02:14 PM 3/22/2008 +, Paul Moore wrote:
>For the system Python, I need:
>- a single way to list what's installed (including version)
>- a single way to uninstall items as needed
>- a way (or more than one) to install 3rd party software *which ties
>into the above*
Right, and the PEP effort
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 17, 2008, at 12:27 AM, Martin v. Löwis wrote:
>> 'critical' is fine (or 'immediate'). My problem before was that I
>> couldn't do one query that gave me all the critical issues for
>> both 2.6 and 3.0. That certainly could have been pebk
At 12:33 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>I probably should have brought this up, in fact, I think I
>>mentioned it in a previous thread, but I would like to see PEP 262
>>add a way to say "this is a system-installed package, *don't
>>touch*". The idea again is not to do the job of
At 11:00 AM 3/22/2008 +, Floris Bruynooghe wrote:
>As long as systems (dpkg, rpm, ...) install the .egg-info files they
>do communicate which modules/distributions are installed. The
>installdb would just duplicate this information (according to the
>current PEP).
.egg-info/PKG-INFO don't lis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 21, 2008, at 5:28 PM, Paul Moore wrote:
>
> One thing I really like the idea of with Mercurial for my situation
> (non-committer) is the mq extension, which lets me manage my changes
> as a "stack of patches" - so I'm completely working with pat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 20, 2008, at 5:49 PM, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> I'm happy to announce that we now have available for public
>> consumption, the Python source code for 2.5, 2.6 and 3.0 available
>> under the Bazaar distributed version co
"Martin v. Löwis" wrote:
>>> Essentially, one would have to contribute patches to all the
>>> distributions (we care about, at least), and then nag the respective
>>> maintainers to include these patches.
>>
>> Not true. You just need to make sure that "setup.py install" creates
>> that database
On 22/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> > One point, which I assume you know but others may not - a bazaar
> > "checkout" is not like a local branch. In a checkout, all commits go
> > straight back to the parent branch, meaning that local commits aren't
> > possible (OK, that
On 22/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> How would you install multiple versions in the first place? Python
> supports no such thing, at least not without setting PYTHONPATH,
> or otherwise changing sys.path.
That's an unrelated feature of setuptools, providing a way to
"ins
>> Essentially, one would have to contribute patches to all the
>> distributions (we care about, at least), and then nag the respective
>> maintainers to include these patches.
>
> Not true. You just need to make sure that "setup.py install" creates
> that database. With the proposed format of
On 22/03/2008, Alexander Michael <[EMAIL PROTECTED]> wrote:
> > IOW, the PEP is lacking a rationale.
>
> It seems to me that this discussion is being undermined by not
> acknowledging the many use cases up front. There is no rationale
> because there are too many tacit rationales.
Absolutely!
> It seems to me that this discussion is being undermined by not
> acknowledging the many use cases up front. There is no rationale
> because there are too many tacit rationales.
I honestly, really, cannot imagine what those are. Explicit is
better than implicit.
> Nevertheless, the many
> use ca
On 22/03/2008, Steve Holden <[EMAIL PROTECTED]> wrote:
> Well, I've probably been killfiled into non-existence on this list by
> now, but it seems to me that we are in danger of answering the wrong
> problem yet again. But that's all I have to say on this topic, so you
> can all heave a sigh a r
On Sat, Mar 22, 2008 at 7:39 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Bazaar supports lightweight checkouts which act like svn checkouts.
> > They are also actively working on allowing for partial checkouts. That
> > way you can eithe
On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Bazaar supports lightweight checkouts which act like svn checkouts.
> They are also actively working on allowing for partial checkouts. That
> way you can either specify an initial revision to pull the history
> down to or start with an in
Hi,
the newest version of Sphinx supports testing doctest (and other) snippets
in the documentation. Since we have many examples in the docs that may
get out of date, I think this is a valuable thing to have.
I've started making the doctests runnable with Sphinx in three documents;
the functiona
Hi all,
I propose a small change on the "from"-import behavior. Currently there are two
ways to import a module name foo from bar. Namely "import foo.bar as bar" and
"from foo import bar". The main problem with the second is that it will not
work in every situation.
Modules are registered wit
> Ok, well, I have a rationale for it: make it possible to get rid of eggs
> as a mechanism for supporting easy_install. Many people (yourself
> included) have criticized eggs as an installation mechanism, and this is
> an alternative that gets rid of .egg files and directories in that case,
>
M.-A. Lemburg wrote:
> On 2008-03-21 22:21, Phillip J. Eby wrote:
>> At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>>> I guess the only way to support all of these variants is
>>> to use a filesystem based approach, e.g. by placing a file
>>> with a special extension into some dir on sys.path.
Another use case, which I find in my world, is that there are always
packages that interest me (found at pypi), that my vendor hasn't packaged
as rpms yet.
With finite resources, this will always be true.
___
Python-Dev mailing list
Python-Dev@python.or
Antoine Pitrou schrieb:
> Ralf Schmitt gmail.com> writes:
>>
>> I have also setup a mirror using mercurial: http://hgpy.de/py/It contains the
> 2.4, 2.5, trunk and py3k branches (in case anyone wants to compare this to
> bzr).
>
> I see your trunk history is stripped. For those who want the com
Matthieu Brucher schrieb:
> Good, because between this now and pytz the other 63 projects I
> follow use
> Subversion or Mercurial.
> Bazaar seems to be mostly limited to Ubuntu users and stuff
> Canonical does,
> so the choice for a Bazaar setup next to Subversion strikes
On 22 Mar, 2008, at 2:44, A.M. Kuchling wrote:
On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
I'm making the assumption that the author(s) of PEP 262 had good
reason for including what they did, rather than assuming that we
should start the entire process over from scratch.
T
55 matches
Mail list logo
