Re: [Python-Dev] Removing __del__

[Nick Coghlan]

Adding pydev back in, since these seem like reasonable questions to me :)

Jim Jewett wrote:
> On 9/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>  # Create a class with the same instance attributes
>>  # as the original
>>  class attr_holder(object):
>>  pass
>>  finalizer_arg = attr_holder()
>>  finalizer_arg.__dict__ = self.__dict__
> 
> Does this really work?

It works for normal user-defined classes at least:

 >>> class C1(object):
... pass
...
 >>> class C2(object):
... pass
...
 >>> a = C1()
 >>> b = C2()
 >>> b.__dict__ = a.__dict__
 >>> a.x = 1
 >>> b.x
1

> (1)  for classes with a dictproxy of some sort, you might get either a
> copy (which isn't updated)

Classes that change the way __dict__ is handled would probably need to define 
their own __del_arg__.

> (2)  for other classes, self might be added to the dict later

Yeah, that's the strongest argument I know of against having that default 
fallback - it can easily lead to a strong reference from sys.finalizers into 
an otherwise unreachable cycle. I believe it currently takes two __del__ 
methods to prevent a cycle from being collected, whereas in this set up it 
would only take one.

OTOH, fixing it would be much easier than it is now (by setting __del_args__ 
to something that holds only the subset of attributes that require 
finalization).

> and of course, if it isn't added later, then it doesn't hvae the full
> power of current finalizers -- just the __close__ subset.

True, but most finalizers I've seen don't really *need* the full power of the 
current __del__. They only need to get at a couple of their internal members 
in order to explicitly release external resources.

And more sophisticated usage is still possible by assigning an appropriate 
value to __del_arg__.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Removing __del__

[Nick Coghlan]

Nick Coghlan wrote:
> Adding pydev back in, since these seem like reasonable questions to me :)

D'oh, that should have been python-3000 not python-dev :(

Sorry for the noise, folks.

Cheers,
Nick.


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] IronPython and AST branch

[Nick Coghlan]

Guido van Rossum wrote:
> On 9/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> One of the biggest issues I have with the current AST is that I don't 
>> believe
>> it really gets the "slice" and "extended slice" terminology correct 
>> (it uses
>> 'extended slice' to refer to multi-dimensional indexing, but the normal
>> meaning of that phrase is to refer to the use of a step argument for a 
>> slice [1])
> 
> The two were introduced together and were referred to together as
> "extended slicing" at the time, so I'm not sure who is confused.

Ah, that would explain it then - I first encountered the phrase 'extended 
slicing' in the context of the Python 2.3 additions to the builtin types, so I 
didn't realise it referred to all __getitem__ based non-mapping lookups, 
rather than just the start:stop:step form of slicing.

Given that additional bit of history, I don't think changing the name of the 
AST node is worth the hassle - I'll just have to recalibrate my brain :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

[Python-Dev] release25-maint is UNFROZEN

[Anthony Baxter]

Ok - it's been 48 hours, and I've not seen any brown-paper-bag bugs, so I'm 
declaring the 2.5 maintenance branch open for business. As specified in 
PEP-006, this is a maintenance branch only suitable for bug fixes. No 
functionality changes should be checked in without discussion and agreement 
on python-dev first.

Thanks to everyone for helping make 2.5 happen. It's been a long slog there, 
but I think we can all be proud of the result.

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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

[Python-Dev] GCC 4.x incompatibility

[Georg Brandl]

Is it noted somewhere that building Python with GCC 4.x results in
problems such as abs(-sys.maxint-1) being negative?

I think this is something users may want to know.


Perhaps the "Known Bugs" page at 
http://www.python.org/download/releases/2.5/bugs/ is the right place to put
this info.

Georg

___
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

Re: [Python-Dev] release25-maint is UNFROZEN

[Armin Rigo]

Hi Anthony,

On Thu, Sep 21, 2006 at 09:12:03PM +1000, Anthony Baxter wrote:
> Thanks to everyone for helping make 2.5 happen. It's been a long slog there, 
> but I think we can all be proud of the result.

Thanks for the hassle!  I've got another bit of it for you, though.  The
freezed 2.5 documentation doesn't seem to be available on-line.  At
least, the doc links from the release page point to the 'dev' 2.6a0
version, and the URL following the common scheme -
http://www.python.org/doc/2.5/ - doesn't work.


A bientot,

Armin
___
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

Re: [Python-Dev] New relative import issue

[Steve Holden]

Guido van Rossum wrote:
> On 9/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 
>>I haven't really thought it through in detail. It
>>just seems as though it would be a lot less confusing
>>if you could figure out from static information which
>>module will get imported by a given import statement,
>>instead of having it depend on the history of run-time
>>modifications to sys.path. One such kind of static
>>information is the layout of the filesystem.
> 
> 
> Eek? If there are two third-party top-level packages A and B, by
> different third parties, and A depends on B, how should A find B if
> not via sys.path or something that is sufficiently equivalent as to
> have the same problems? Surely every site shouldn't be required to
> install A and B in the same location (or in the same location relative
> to each other).
> 
> I sympathize with the problems that exist with the current import
> mechanism, really, I do. Google feels the pain every day (alas,
> Google's requirements are a bit unusual, so they alone can't provide
> much guidance for a solution). But if you combine the various
> requirements: zip imports, import hooks of various sorts, different
> permissions for the owners of different packages that must cooperate,
> versioning issues (Python versions as well as package versions),
> forwards compatibility, backwards compatibility, ease of development,
> ease of packaging, ease of installation, supporting the conventions of
> vastly different platforms, data files mixed in with the source code
> (sometimes with their own search path), and probably several other
> requirements that I'm forgetting right now, it's just not an easy
> problem.
> 
But you're the BDFL! You mean to tell me there are some problems you 
can't solve?!?!?!?!?

shocked-and-amazed-ly y'rs  - steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb   http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

___
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

Re: [Python-Dev] New relative import issue

[Giovanni Bajo]

Oleg Broytmann wrote:

>> There really shouldn't be
>> any such thing as sys.path -- the view that any
>> given module has of the package namespace should
>> depend only on where it is
>
>I do not understand this. Can you show an example? Imagine I have
> two servers, Linux and FreeBSD, and on Linux python is in /usr/bin,
> home is /home/phd, on BSD these are /usr/local/bin and /usr/home/phd.
> I have some modules in site-packages and some modules in
> $HOME/lib/python. How can I move programs from one server to the
> other without rewriting them (how can I not to put full paths to
> modules)? I use PYTHONPATH manipulation - its enough to write a shell
> script that starts daemons once and use it for many years. How can I
> do this without sys.path?!

My idea (and interpretation of Greg's statement) is that a module/package
should be able to live with either relative imports within itself, or fully
absolute imports. No sys.path *hackery* should ever be necessary to access
modules in sibling namespaces. Either it's an absolute import, or a relative
(internal) import. A sibling import is a symptom of wrong design of the
packages.

This is how I usually design my packages at least. There might be valid use
cases for doing sys.path hackery, but I have yet to find them.
-- 
Giovanni Bajo

___
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

[Python-Dev] dict.discard

[Gustavo Niemeyer]

Hey guys,

After trying to use it a few times with no success :-), I'd like
to include a new method, dict.discard, mirroring set.discard:

  >>> print set.discard.__doc__
  Remove an element from a set if it is a member.
  
  If the element is not a member, do nothing.

Comments?

-- 
Gustavo Niemeyer
http://niemeyer.net
___
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

Re: [Python-Dev] dict.discard

[Fred L. Drake, Jr.]

On Thursday 21 September 2006 09:42, Gustavo Niemeyer wrote:
 > After trying to use it a few times with no success :-), I'd like
 >
 > to include a new method, dict.discard, mirroring set.discard:
 >   >>> print set.discard.__doc__
 >
 >   Remove an element from a set if it is a member.
 >
 >   If the element is not a member, do nothing.

Would the argument be the key, or the pair?  I'd guess the key.

If so, there's the 2-arg flavor of dict.pop():

  >>> d = {}
  >>> d.pop("key", None)

It's not terribly obvious, but does the job without enlarging the dict API.


  -Fred

-- 
Fred L. Drake, Jr.   
___
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

Re: [Python-Dev] dict.discard

[Gustavo Niemeyer]

> Would the argument be the key, or the pair?  I'd guess the key.

Right, the key.

> If so, there's the 2-arg flavor of dict.pop():
> 
>   >>> d = {}
>   >>> d.pop("key", None)
> 
> It's not terribly obvious, but does the job without enlarging
> the dict API.

Yeah, this looks good.  I don't think I've ever used it like this.

-- 
Gustavo Niemeyer
http://niemeyer.net
___
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

Re: [Python-Dev] Small Py3k task: fix modulefinder.py

[Thomas Heller]

Guido van Rossum schrieb:
> Is anyone familiar enough with modulefinder.py to fix its breakage in
> Py3k? It chokes in a nasty way (exceeding the recursion limit) on the
> relative import syntax. I suspect this is also a problem for 2.5, when
> people use that syntax; hence the cross-post. There's no unittest for
> modulefinder.py, but I believe py2exe depends on it (and of course
> freeze.py, but who uses that still?)
> 

I'm not (yet) using relative imports in 2.5 or Py3k, but have not been able
to reproduce the recursion limit problem.  Can you describe the package
that fails?

Thanks,
Thomas

___
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

Re: [Python-Dev] New relative import issue

[Guido van Rossum]

On 9/21/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> >> Greg Eqing wrote:
> >> There really shouldn't be
> >> any such thing as sys.path -- the view that any
> >> given module has of the package namespace should
> >> depend only on where it is

> My idea (and interpretation of Greg's statement) is that a module/package
> should be able to live with either relative imports within itself, or fully
> absolute imports. No sys.path *hackery* should ever be necessary to access
> modules in sibling namespaces. Either it's an absolute import, or a relative
> (internal) import. A sibling import is a symptom of wrong design of the
> packages.
>
> This is how I usually design my packages at least. There might be valid use
> cases for doing sys.path hackery, but I have yet to find them.

While I agree with your idea(l), I don't think that's what Greg meant.
He clearly say "sys.path should not exist at all".

I do think it's fair to use sibling imports (using from ..sibling
import module) from inside subpackages of the same package; I couldn't
tell if you were against that or not.

sys.path exists to stitch together the toplevel module/package
namespace from diverse sources.

Import hooks and sys.path hackery exist so that module/package sources
don't have to be restricted to the filesystem (as well as to allow
unbridled experimentation by those so inclined :-).

I think one missing feature is a mechanism whereby you can say "THIS
package (gives top-level package name) lives HERE (gives filesystem
location of package)" without adding the parent of HERE to sys.path
for all module searches. I think Phillip Eby's egg system might
benefit from this.

Another missing feature is a mechanism whereby you can use a
particular file as the main script without adding its directory to the
front of sys.path.

Other missing features have to do with versioning constraints. But
that quickly gets extremely messy.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Python-Dev] win32 - results from Lib/test - 2.5 release-maint

[Grzegorz Makarewicz]

Hi,

- *.txt files for unicode tests are downloaded from internet - I don't 
like this.
- __db.004 isn't removed after tests
- init_types is declared static in python/python-ast.c and cant be 
imported from PC/config.c.
- python_d -u regrtest.py -u bsddb -u curses -uall -v = dies after 
testInfinitRecursion  without any message, just dissapears from tasks 
and doesn't show anything

mak

___
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

Re: [Python-Dev] GCC 4.x incompatibility

[Martin v. Löwis]

Georg Brandl schrieb:
> Is it noted somewhere that building Python with GCC 4.x results in
> problems such as abs(-sys.maxint-1) being negative?

Yes, it's in the README (although it claims problems only exist with
4.1 and 4.2; 4.0 seems to work fine for me).

> I think this is something users may want to know.

See what I wrote. Users are advised to either not use that compiler,
or add -fwrapv.

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

Re: [Python-Dev] win32 - results from Lib/test - 2.5 release-maint

[Brett Cannon]

On 9/21/06, Grzegorz Makarewicz <[EMAIL PROTECTED]> wrote:
Hi,- *.txt files for unicode tests are downloaded from internet - I don'tlike this.Then don't use the urlfetch resource when running regrtest.py (which you did specify when you ran with ``-uall``).
- __db.004 isn't removed after tests- init_types is declared static in python/python-
ast.c and cant beimported from PC/config.c.- python_d -u regrtest.py -u bsddb -u curses -uall -v = dies aftertestInfinitRecursion  without any message, just dissapears from tasksand doesn't show anything
Please file a bug report for each of these issues.-Brett 
___
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

Re: [Python-Dev] win32 - results from Lib/test - 2.5 release-maint

[Martin v. Löwis]

Please submit a patch to sf.net/projects/python.

> - *.txt files for unicode tests are downloaded from internet - I don't 
> like this.

What files specifcally? Could it be that you passed -u urlfetch
or -u all? If so, then just don't.

> - init_types is declared static in python/python-ast.c and cant be 
> imported from PC/config.c.

Why is that a problem? PC/config.c refers to Modules/_typesmodule.c.

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

Re: [Python-Dev] release25-maint is UNFROZEN

[Neal Norwitz]

On 9/21/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Anthony,
>
> On Thu, Sep 21, 2006 at 09:12:03PM +1000, Anthony Baxter wrote:
> > Thanks to everyone for helping make 2.5 happen. It's been a long slog there,
> > but I think we can all be proud of the result.
>
> Thanks for the hassle!  I've got another bit of it for you, though.  The
> freezed 2.5 documentation doesn't seem to be available on-line.  At
> least, the doc links from the release page point to the 'dev' 2.6a0
> version, and the URL following the common scheme -
> http://www.python.org/doc/2.5/ - doesn't work.

I got  http://docs.python.org/dev/2.5/ working last night.  So when
the 2.5 docs are updated these pages will reflect that.

http://docs.python.org/ should point to the 2.5 doc too.  I looked at
making these changes, but was confused by what needed to be done.

n
___
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

Re: [Python-Dev] New relative import issue

[Paul Moore]

On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think one missing feature is a mechanism whereby you can say "THIS
> package (gives top-level package name) lives HERE (gives filesystem
> location of package)" without adding the parent of HERE to sys.path
> for all module searches. I think Phillip Eby's egg system might
> benefit from this.

This is pretty easy to do with a custom importer on sys.meta_path.
Getting the details right is a touch fiddly, but it's conceptually
straightforward.

Hmm, I might play with this - a set of PEP 302 importers to completely
customise the import mechanism. The never-completed "phase 2" of the
PEP included a reimplementation of the built in import mechanism as
hooks. Is there any interest in this actually happening? I've been
looking for an interesting coding project for a while (although I
never have any free time...)

Paul.
___
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

Re: [Python-Dev] New relative import issue

[Guido van Rossum]

On 9/21/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I think one missing feature is a mechanism whereby you can say "THIS
> > package (gives top-level package name) lives HERE (gives filesystem
> > location of package)" without adding the parent of HERE to sys.path
> > for all module searches. I think Phillip Eby's egg system might
> > benefit from this.
>
> This is pretty easy to do with a custom importer on sys.meta_path.
> Getting the details right is a touch fiddly, but it's conceptually
> straightforward.

Isn't the main problem how to specify a bunch of these in the
environment? Or can this be done through .pkg files? Those aren't
cheap either though -- it would be best if the work was only done when
the package is actually needed.

> Hmm, I might play with this - a set of PEP 302 importers to completely
> customise the import mechanism. The never-completed "phase 2" of the
> PEP included a reimplementation of the built in import mechanism as
> hooks. Is there any interest in this actually happening? I've been
> looking for an interesting coding project for a while (although I
> never have any free time...)

There's a general desire to reimplement import entirely in Python for
more flexibility. I believe Brett Cannon is working on this.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] New relative import issue

[Paul Moore]

On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:

On 9/21/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I think one missing feature is a mechanism whereby you can say "THIS
> > package (gives top-level package name) lives HERE (gives filesystem
> > location of package)" without adding the parent of HERE to sys.path
> > for all module searches. I think Phillip Eby's egg system might
> > benefit from this.
>
> This is pretty easy to do with a custom importer on sys.meta_path.
> Getting the details right is a touch fiddly, but it's conceptually
> straightforward.

Isn't the main problem how to specify a bunch of these in the
environment? Or can this be done through .pkg files? Those aren't
cheap either though -- it would be best if the work was only done when
the package is actually needed.


Hmm, I wasn't thinking of the environment. I pretty much never use
PYTHONPATH, so I tend to forget about that aspect. I was assuming an
importer object with a "register(package_name, filesystem_path)"
method. Then register the packages you want in your code, or in
site.py.

I've attached a trivial proof of concept.

But yes, you'd need to consider the environment. Possibly just have an
initialisation function called at load time (I'm assuming the new hook
is defined in a system module of some sort - I mean when that system
module is loaded) which parses an environment variable and issues a
set of register() calls.

Paul.
import sys
import imp

class Importer(object):
def __init__(self):
	self.registered_modules = {}
def register(self, fullname, filename):
	self.registered_modules[fullname] = filename
def find_module(self, fullname, path=None):
	if path is None:
	return Loader(self)

class Loader(object):
def __init__(self, importer):
	self.importer = importer
def load_module(self, fullname):
	print "Trying", fullname
	filename = self.importer.registered_modules.get(fullname)
	if filename:
	print fullname, "was registered - load from", filename
	# Create a dummy for now, as I don't have time to code the full
	# filesystem lookup.
	mod = sys.modules.setdefault(fullname, imp.new_module(fullname))
	mod.__file__ = "<%s>" % self.__class__.__name__
	mod.__loader__ = self
	mod.__path__ = [filename]
	exec "pass" in mod.__dict__
	return mod

importer = Importer()
sys.meta_path.append(importer)

# Put code here to register module/path pairs from an environment variable
# ...

if __name__ == '__main__':
# Trivial test
importer.register("a", "C:\\Whatever")
# C:\Whatever needs to contain a subdir b, containing __init__.py and c.py
import a.b.c
___
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

Re: [Python-Dev] New relative import issue

[Phillip J. Eby]

At 01:54 PM 9/21/2006 -0700, Guido van Rossum wrote:
>On 9/21/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> > On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I think one missing feature is a mechanism whereby you can say "THIS
> > > package (gives top-level package name) lives HERE (gives filesystem
> > > location of package)" without adding the parent of HERE to sys.path
> > > for all module searches. I think Phillip Eby's egg system might
> > > benefit from this.
> >
> > This is pretty easy to do with a custom importer on sys.meta_path.
> > Getting the details right is a touch fiddly, but it's conceptually
> > straightforward.
>
>Isn't the main problem how to specify a bunch of these in the
>environment?

Yes, that's exactly the problem, assuming that by environment you mean the 
operating environment, as opposed to e.g. os.environ.  (Environment 
variables are problematic for installation purposes, as on Unix-y systems 
there is no one obvious place to set them, and on Windows, the one obvious 
place is one that the user may have no permissions for!)

___
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

[Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Grig Gheorghiu]

One of the Pybots buildslaves has been failing the 'test' step, with
the culprit being test_itertools:

test_itertools
test test_itertools failed -- Traceback (most recent call last):
  File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_itertools.py",
line 62, in test_count
self.assertEqual(repr(c), 'count(-9)')
AssertionError: 'count(4294967287)' != 'count(-9)'

This started to happen after
.

The complete log for the test step on that buildslave is here:

http://www.python.org/dev/buildbot/community/all/x86%20OSX%20trunk/builds/19/step-test/0

Grig


-- 
http://agiletesting.blogspot.com
___
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

Re: [Python-Dev] New relative import issue

[Paul Moore]

On 9/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >Isn't the main problem how to specify a bunch of these in the
> >environment?
>
> Yes, that's exactly the problem, assuming that by environment you mean the
> operating environment, as opposed to e.g. os.environ.

Hmm, now I don't understand again. What "operating environment" might
there be, other than

- os.environ
- code that gets executed before the import

?

There are clearly application design issues involved here (application
configuration via initialisation files, plugin registries, etc etc).
But in purely technical terms, don't they all boil down to executing a
registration function (either directly by the user, or by the
application on behalf of the user)?

I don't think I'd expect anything at the language (or base library)
level beyond a registration function and possibly an OS environment
check.

Paul.
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

The python binary is out of step with the test_itertools.py version.
You can generate this same error on your own box by reverting the
change to itertoolsmodule.c but leaving the new test in test_itertools.py

I don't know why this only happened on that OSX buildslave

On Thu, Sep 21, 2006 at 02:34:40PM -0700, Grig Gheorghiu wrote:
> One of the Pybots buildslaves has been failing the 'test' step, with
> the culprit being test_itertools:
> 
> test_itertools
> test test_itertools failed -- Traceback (most recent call last):
>   File
> "/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_itertools.py",
> line 62, in test_count
> self.assertEqual(repr(c), 'count(-9)')
> AssertionError: 'count(4294967287)' != 'count(-9)'
> 
> This started to happen after
> .
> 
> The complete log for the test step on that buildslave is here:
> 
> http://www.python.org/dev/buildbot/community/all/x86%20OSX%20trunk/builds/19/step-test/0
> 
> Grig
> 
> 
> -- 
> http://agiletesting.blogspot.com
> ___
> 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/jackdied%40jackdied.com
> 
___
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

Re: [Python-Dev] New relative import issue

[Brett Cannon]

On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 9/21/06, Paul Moore <[EMAIL PROTECTED]> wrote:[SNIP]> Hmm, I might play with this - a set of PEP 302 importers to completely> customise the import mechanism. The never-completed "phase 2" of the
> PEP included a reimplementation of the built in import mechanism as> hooks. Is there any interest in this actually happening? I've been> looking for an interesting coding project for a while (although I
> never have any free time...)There's a general desire to reimplement import entirely in Python formore flexibility. I believe Brett Cannon is working on this.Since I need to control imports to the point of being able to deny importing built-in and extension modules, I was planning on re-implementing the import system to use PEP 302 importers.  Possibly do it in pure Python for ease-of-use.  Then that can be worked off of for possible Py3K improvements to the import system.
But either way I will be messing with the import system in the relatively near future.  If you want to help, Paul (or anyone else), just send me an email and we can try to coordinate something (plan to do the work in the sandbox as a separate thing from my security stuff).
-Brett
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Grig Gheorghiu]

On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> The python binary is out of step with the test_itertools.py version.
> You can generate this same error on your own box by reverting the
> change to itertoolsmodule.c but leaving the new test in test_itertools.py
>
> I don't know why this only happened on that OSX buildslave

Not sure what you mean by out of step. The binary was built out of the
very latest itertoolsmodule.c, and test_itertools.py was also updated
from svn. So they're both in sync IMO. That tests passes successfully
on all the other buildslaves in the Pybots farm (x86 Ubuntu, Debian,
Gentoo, RH9, AMD-64 Ubuntu)

Grig
___
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

Re: [Python-Dev] New relative import issue

[Guido van Rossum]

On 9/21/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Isn't the main problem how to specify a bunch of these in the
> > environment? Or can this be done through .pkg files? Those aren't
> > cheap either though -- it would be best if the work was only done when
> > the package is actually needed.
>
> Hmm, I wasn't thinking of the environment. I pretty much never use
> PYTHONPATH, so I tend to forget about that aspect.

As Phillip understood, I meant the environment to include the
filesystem (and on Windows, the registry -- in fact, Python on Windows
*has* exactly such a mechanism in the registry, although I believe
it's rarely used these days -- it was done by Mark Hammond to support
COM servers I believe.)

> I was assuming an
> importer object with a "register(package_name, filesystem_path)"
> method. Then register the packages you want in your code, or in
> site.py.

Neither is an acceptable method for an installer tool (e.g. eggs) to
register new packages. it needs to be some kind of data file or set of
data files.

> But yes, you'd need to consider the environment. Possibly just have an
> initialisation function called at load time (I'm assuming the new hook
> is defined in a system module of some sort - I mean when that system
> module is loaded) which parses an environment variable and issues a
> set of register() calls.

os.environ is useless because there's no way for a package installer
to set it for all users.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Python-Dev] Weekly Python Patch/Bug Summary ** REVISED **

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  420 open ( +4) /  3410 closed ( +2) /  3830 total ( +6)
Bugs:  915 open (+17) /  6186 closed ( +6) /  7101 total (+23)
RFE :  235 open ( +1) /   238 closed ( +0) /   473 total ( +1)

New / Reopened Patches
__

Practical ctypes example  (2006-09-15)
   http://python.org/sf/1559219  opened by  leppton

test_popen fails on Windows if installed to "Program Files"  (2006-09-15)
   http://python.org/sf/1559298  opened by  Martin v. Löwis

test_cmd_line fails on Windows  (2006-09-15)
   http://python.org/sf/1559413  opened by  Martin v. Löwis

pyclbr reports different module for Class and Function  (2006-09-18)
   http://python.org/sf/1560617  opened by  Peter Otten

Exec stacks in python 2.5  (2006-09-18)
   http://python.org/sf/1560695  opened by  Chaza

Python 2.5 fails with -Wl,--as-needed in LDFLAGS  (2006-09-21)
   http://python.org/sf/1562825  opened by  Chaza

Patches Closed
__

test_grp.py doesn't skip special NIS entry, fails  (2006-06-22)
   http://python.org/sf/1510987  closed by  martineau

Add RLIMIT_SBSIZE to resource module  (2006-09-13)
   http://python.org/sf/1557515  closed by  loewis

New / Reopened Bugs
___

some section links (previous, up, next) missing last word  (2006-09-15)
   http://python.org/sf/1559142  opened by  Tim Smith

time.strptime() access non exitant attribute in calendar.py  (2006-09-15)
CLOSED http://python.org/sf/1559515  opened by  betatim

shutil.copyfile incomplete on NTFS  (2006-09-16)
   http://python.org/sf/1559684  opened by  Roger Upole

gcc trunk (4.2) exposes a signed integer overflows  (2006-08-24)
   http://python.org/sf/1545668  reopened by  arigo

2.5c2 pythonw does not execute  (2006-09-16)
CLOSED http://python.org/sf/1559747  opened by  Ron Platten

list.sort does nothing when both cmp and key are given  (2006-09-16)
CLOSED http://python.org/sf/1559818  opened by  Marcin 'Qrczak' Kowalczyk

confusing error msg from random.randint  (2006-09-17)
   http://python.org/sf/1560032  opened by  paul rubin

Tutorial: incorrect info about package importing and mac  (2006-09-17)
   http://python.org/sf/1560114  opened by  C L

Better/faster implementation of os.path.split  (2006-09-17)
CLOSED http://python.org/sf/1560161  opened by  Michael Gebetsroither

Better/faster implementation of os.path.basename/dirname  (2006-09-17)
   http://python.org/sf/1560179  reopened by  gbrandl

Better/faster implementation of os.path.basename/dirname  (2006-09-17)
   http://python.org/sf/1560179  opened by  Michael Gebetsroither

copy() method of dictionaries is not "deep"  (2006-09-17)
   http://python.org/sf/1560327  reopened by  gbrandl

copy() method of dictionaries is not "deep"  (2006-09-17)
   http://python.org/sf/1560327  opened by  daniel hahler

strftime('%z') behaving differently with/without time arg.  (2006-09-18)
   http://python.org/sf/1560794  opened by  Knut Aksel Røysland

python 2.5 fails to build with --as-needed  (2006-09-18)
   http://python.org/sf/1560984  opened by  Chaza

mac installer profile patch vs. .bash_login  (2006-09-19)
   http://python.org/sf/1561243  opened by  Ronald Oussoren

-xcode=pic32 option is not supported on Solaris x86 Sun C  (2006-09-19)
   http://python.org/sf/1561333  opened by  James Lick

Dedent with Italian keyboard  (2006-09-20)
   http://python.org/sf/1562092  opened by  neclepsio

Fails to install on Fedora Core 5  (2006-09-20)
   http://python.org/sf/1562171  opened by  Mark Summerfield

IDLE Hung up after open script by command line...  (2006-09-20)
   http://python.org/sf/1562193  opened by  Faramir^

uninitialized memory read in parsetok()  (2006-09-20)
   http://python.org/sf/1562308  opened by  Luke Moore

asyncore.dispatcher.set_reuse_addr not documented.  (2006-09-20)
   http://python.org/sf/1562583  opened by  Noah Spurrier

Spurious tab/space warning  (2006-09-21)
   http://python.org/sf/1562716  opened by  torhu

Spurious Tab/space error  (2006-09-21)
   http://python.org/sf/1562719  opened by  torhu

decimal module borks thread  (2006-09-21)
   http://python.org/sf/1562822  opened by  Jaster

MacPython ignores user-installed Tcl/Tk  (2006-09-21)
   http://python.org/sf/1563046  opened by  Russell Owen

code.InteractiveConsole() and closed sys.stdout  (2006-09-21)
   http://python.org/sf/1563079  opened by  Skip Montanaro

Bugs Closed
___

2.5c2 macosx installer aborts during "GUI Applications"  (2006-09-15)
   http://python.org/sf/1558983  closed by  ronaldoussoren

time.strptime() access non existant attribute in calendar.py  (2006-09-15)
   http://python.org/sf/1559515  closed by  bcannon

2.5c2 pythonw does not execute  (2006-09-16)
   http://python.org/sf/1559747  closed by  loewis

list.sort does nothing when both cmp and key are given  (2006-09-16)
   http://py

Re: [Python-Dev] New relative import issue

[Phillip J. Eby]

At 03:28 PM 9/21/2006 -0700, Guido van Rossum wrote:
>os.environ is useless because there's no way for a package installer
>to set it for all users.

Or even for *one* user!  :)

___
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

Re: [Python-Dev] New relative import issue

[Greg Ewing]

Guido van Rossum wrote:

> Eek? If there are two third-party top-level packages A and B, by
> different third parties, and A depends on B, how should A find B if
> not via sys.path or something that is sufficiently equivalent as to
> have the same problems?

Some kind of configuration mechanism is needed, but
I don't see why it can't be a static, declarative one
rather than computed at run time.

Whoever installs package A should be responsible for
setting up whatever environment is necessary around it
for it to find package B and anything else it directly
depends on.

The program C which uses package A needs to be told
where to find it. But C doesn't need to know where to
find B, the dependency on which is an implementation
detail of A, because A already knows where to find it.

In the Eiffel world, there's a thing called and ACE
(Assembly of Classes in Eiffel), which is a kind of
meta-language for describing the shape of the class
namespace, and it allows each source file to have its
own unique view of that namespace. I'm groping towards
something equivalent for the Python module namespace.
(AMP - Assembly of Modules in Python?)

--
Greg

___
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

Re: [Python-Dev] New relative import issue

[Greg Ewing]

Another thought on static module namespace configuration:
It would make things a *lot* easier for py2exe, py2app
and the like that have to figure out what packages
a program depends on without running the program.

--
Greg
___
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

Re: [Python-Dev] New relative import issue

[Phillip J. Eby]

At 12:07 PM 9/22/2006 +1200, Greg Ewing wrote:
>Another thought on static module namespace configuration:
>It would make things a *lot* easier for py2exe, py2app
>and the like that have to figure out what packages
>a program depends on without running the program.

Setuptools users already explicitly declare what projects their projects 
depend on; this is how easy_install can then find and install those 
dependencies.  So, there is at least one system already available for 
Python that manages this type of thing already, and my understanding is 
that the py2exe and py2app developers plan to support using this dependency 
information in the future.

___
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

Re: [Python-Dev] New relative import issue

[Guido van Rossum]

On 9/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Eek? If there are two third-party top-level packages A and B, by
> > different third parties, and A depends on B, how should A find B if
> > not via sys.path or something that is sufficiently equivalent as to
> > have the same problems?
>
> Some kind of configuration mechanism is needed, but
> I don't see why it can't be a static, declarative one
> rather than computed at run time.

That would preclude writing the code that interprets the static data
in Python itself.

Despite the good use cases I think that's a big showstopper.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] New relative import issue

[Greg Ewing]

Giovanni Bajo wrote:

> My idea (and interpretation of Greg's statement) is that a module/package
> should be able to live with either relative imports within itself, or fully
> absolute imports.

I think it goes further than that -- each module should
(potentially) have its own unique view of the module
namespace, defined at the time the module is installed,
that can't be disturbed by anything that any other module
does.

--
Greg
___
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

Re: [Python-Dev] New relative import issue

[Guido van Rossum]

I think it would be worth writing up a PEP to describe this, if it's
to become a de-facto standard. That might be a better path towards
standardization than just checking in the code... :-/

--Guido

On 9/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:07 PM 9/22/2006 +1200, Greg Ewing wrote:
> >Another thought on static module namespace configuration:
> >It would make things a *lot* easier for py2exe, py2app
> >and the like that have to figure out what packages
> >a program depends on without running the program.
>
> Setuptools users already explicitly declare what projects their projects
> depend on; this is how easy_install can then find and install those
> dependencies.  So, there is at least one system already available for
> Python that manages this type of thing already, and my understanding is
> that the py2exe and py2app developers plan to support using this dependency
> information in the future.
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] New relative import issue

[Guido van Rossum]

On 9/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
>
> > My idea (and interpretation of Greg's statement) is that a module/package
> > should be able to live with either relative imports within itself, or fully
> > absolute imports.
>
> I think it goes further than that -- each module should
> (potentially) have its own unique view of the module
> namespace, defined at the time the module is installed,
> that can't be disturbed by anything that any other module
> does.

Well, maybe. But there's also the requirement that if packages A and B
both import C, they should get the same C. Having multiple versions of
the same package loaded simultaneously sounds like a recipe for
disaster.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Python-Dev] list.discard? (Re: dict.discard)

[Greg Ewing]

Gustavo Niemeyer wrote:

>   >>> print set.discard.__doc__
>   Remove an element from a set if it is a member.

Actually I'd like this for lists. Often I find myself
writing

   if x not in somelist:
 somelist.remove(x)

A single method for doing this would be handy, and
more efficient.

--
Greg
___
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

Re: [Python-Dev] list.discard? (Re: dict.discard)

[Fred L. Drake, Jr.]

On Thursday 21 September 2006 20:21, Greg Ewing wrote:
 >if x not in somelist:
 >  somelist.remove(x)

I'm just guessing you really meant "if x in somelist".  ;-)


  -Fred

-- 
Fred L. Drake, Jr.   
___
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

Re: [Python-Dev] New relative import issue

[Greg Ewing]

Guido van Rossum wrote:

> While I agree with your idea(l), I don't think that's what Greg meant.
> He clearly say "sys.path should not exist at all".

Refining that a bit, I don't think there should be
a *single* sys.path for the whole program -- more
like each module having its own sys.path. And, at
least in most cases, its contents should be set
up from static information that exists outside the
program, established when the module is installed.

One reason for this is the lack of any absolute
notion of a "program". What is a program on one
level can be part of a larger program on another
level. For example, a module with test code that
is run when it's invoked as a main script.
Sometimes it's a program of its own, other times
it's not. And it shouldn't *matter* whether it's
a program or not when it comes to being able to
find other modules that it needs to import. So
using a piece of program-wide shared state for
this seems wrong.

--
Greg
___
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

Re: [Python-Dev] New relative import issue

[Scott Dial]

Guido van Rossum wrote:
> On 9/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> I think it goes further than that -- each module should
>> (potentially) have its own unique view of the module
>> namespace, defined at the time the module is installed,
>> that can't be disturbed by anything that any other module
>> does.
> 
> Well, maybe. But there's also the requirement that if packages A and B
> both import C, they should get the same C. Having multiple versions of
> the same package loaded simultaneously sounds like a recipe for
> disaster.

I have exactly this scenario in my current codebase for a server. It was 
absolutely necessary for me to update a module in Twisted because all 
other solutions I could come up with were less desirable. Either I send 
my patch upstream and wait (can't wait), or I fork out another version 
and place it at the top of sys.path (this seems ok). Except an even 
better solution is to maintain my own subset of Twisted, because I am 
localized to a particularly small corner of the codebase. I can continue 
to use upstream updates to the rest of Twisted without any fussing about 
merging changes and so forth. And if Twisted was allowed to decide how 
it saw its own world, then I would have to go back to maintaining my own 
complete branch.

While I don't strictly need to be able to do this, I wanted to at least 
raise my hand and say, "I abuse this facet of the current import 
mechanism."

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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

Re: [Python-Dev] list.discard? (Re: dict.discard)

[Josiah Carlson]

Greg Ewing <[EMAIL PROTECTED]> wrote:
> Gustavo Niemeyer wrote:
> 
> >   >>> print set.discard.__doc__
> >   Remove an element from a set if it is a member.
> 
> Actually I'd like this for lists. Often I find myself
> writing
> 
>if x not in somelist:
>  somelist.remove(x)
> 
> A single method for doing this would be handy, and
> more efficient.

A marginal calling time improvement; but we are still talking linear
time containment test.

I'm -0, if only because I've never really found the need to use
list.remove(), so this API expansion doesn't feel necessary to me.

 - Josiah

___
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

Re: [Python-Dev] New relative import issue

[Phillip J. Eby]

At 12:40 PM 9/22/2006 +1200, Greg Ewing wrote:
>Guido van Rossum wrote:
>
> > While I agree with your idea(l), I don't think that's what Greg meant.
> > He clearly say "sys.path should not exist at all".
>
>Refining that a bit, I don't think there should be
>a *single* sys.path for the whole program -- more
>like each module having its own sys.path. And, at
>least in most cases, its contents should be set
>up from static information that exists outside the
>program, established when the module is installed.

Now I'm a little bit more in agreement with you, but not by much.  :)

In the Java world, the OSGi framework (which is a big inspiration for many 
aspects of setuptools) effectively has a sys.path per installed project 
(modulo certain issues for dynamic imports, which I'll get into more below).

And, when Bob Ippolito and I were first designing the egg runtime system, 
we considered using some hacks to do the same thing, such that you actually 
*could* have more than one version of a package present and being used by 
two other packages that require it.

However, we eventually tossed it as a YAGNI; dependency resolution is too 
damn hard already without also having to deal with crud like C extensions 
only being able to be loaded once, etc., in addition to the necessary 
import hackery.

So, in principle, it's a good idea.  In practice, I don't think it can be 
achieved on the CPython platform.  You need something like a Jython or 
IronPython or a PyPy+ctypes-ish platform, where all the C is effectively 
abstracted behind some barrier that prevents the module problem from 
occurring, and you could in principle load the modules in different 
interpreters (or "class loaders" in the Java context).

Amusingly, this is one of the few instances where every Python *except* 
CPython is probably in a better position to implement the feature...  :)


>One reason for this is the lack of any absolute
>notion of a "program". What is a program on one
>level can be part of a larger program on another
>level. For example, a module with test code that
>is run when it's invoked as a main script.
>Sometimes it's a program of its own, other times
>it's not. And it shouldn't *matter* whether it's
>a program or not when it comes to being able to
>find other modules that it needs to import. So
>using a piece of program-wide shared state for
>this seems wrong.

An interesting point about this is that it coincidentally solves the 
problem of dynamic interpretation of meta-syntactic features.  That is, if 
there is a static way to know what modules are accessible to the module, 
then the resolution of meta-syntax features like macros or custom 
statements is simpler than if a runtime resolution is required.

Of course, in all of this you're still ignoring the part where some modules 
may need to perform dynamic or "weak" imports.  So at least *some* portion 
of a module's import path *is* dependent on the notion of the "current 
program".

(See the documentation for the "Importing" package at 
http://peak.telecommunity.com/DevCenter/Importing for an explanation of 
"weak" importing.)

___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote:
> On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> > The python binary is out of step with the test_itertools.py version.
> > You can generate this same error on your own box by reverting the
> > change to itertoolsmodule.c but leaving the new test in test_itertools.py
> >
> > I don't know why this only happened on that OSX buildslave
> 
> Not sure what you mean by out of step. The binary was built out of the
> very latest itertoolsmodule.c, and test_itertools.py was also updated
> from svn. So they're both in sync IMO. That tests passes successfully
> on all the other buildslaves in the Pybots farm (x86 Ubuntu, Debian,
> Gentoo, RH9, AMD-64 Ubuntu)
> 

When I saw the failure, first I cursed (a lot).  Then I followed the repr
all the way down into stringobject.c, no dice.  Then I noticed that the
failure is exactly what you get if the test was updated but the old
module wasn't.

Faced with the choice of believing in a really strange platform specific 
bug in a commonly used routine that resulted in exactly the failure caused 
by one of the two files being updated or believing a failure occurred in the
long chain of networks, disks, file systems, build tools, and operating 
systems that would result in only one of the files being updated -
I went with the latter.

I'll continue in my belief until my dying day or until someone with OSX
confirms it is a bug, whichever comes first.

not-gonna-sweat-it-ly,

-Jack
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Grig Gheorghiu]

On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote:
> > On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> > > The python binary is out of step with the test_itertools.py version.
> > > You can generate this same error on your own box by reverting the
> > > change to itertoolsmodule.c but leaving the new test in test_itertools.py
> > >
> > > I don't know why this only happened on that OSX buildslave
> >
> > Not sure what you mean by out of step. The binary was built out of the
> > very latest itertoolsmodule.c, and test_itertools.py was also updated
> > from svn. So they're both in sync IMO. That tests passes successfully
> > on all the other buildslaves in the Pybots farm (x86 Ubuntu, Debian,
> > Gentoo, RH9, AMD-64 Ubuntu)
> >
>
> When I saw the failure, first I cursed (a lot).  Then I followed the repr
> all the way down into stringobject.c, no dice.  Then I noticed that the
> failure is exactly what you get if the test was updated but the old
> module wasn't.
>
> Faced with the choice of believing in a really strange platform specific
> bug in a commonly used routine that resulted in exactly the failure caused
> by one of the two files being updated or believing a failure occurred in the
> long chain of networks, disks, file systems, build tools, and operating
> systems that would result in only one of the files being updated -
> I went with the latter.
>
> I'll continue in my belief until my dying day or until someone with OSX
> confirms it is a bug, whichever comes first.
>
> not-gonna-sweat-it-ly,
>
> -Jack
> ___

OK, sorry for having caused you so much griefI'll investigate some
more on the Pybots side and I'll let you know what I find.

Grig
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Grig Gheorghiu]

On 9/21/06, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
> On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote:
> > > On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> > > > The python binary is out of step with the test_itertools.py version.
> > > > You can generate this same error on your own box by reverting the
> > > > change to itertoolsmodule.c but leaving the new test in 
> > > > test_itertools.py
> > > >
> > > > I don't know why this only happened on that OSX buildslave
> > >
> > > Not sure what you mean by out of step. The binary was built out of the
> > > very latest itertoolsmodule.c, and test_itertools.py was also updated
> > > from svn. So they're both in sync IMO. That tests passes successfully
> > > on all the other buildslaves in the Pybots farm (x86 Ubuntu, Debian,
> > > Gentoo, RH9, AMD-64 Ubuntu)
> > >
> >
> > When I saw the failure, first I cursed (a lot).  Then I followed the repr
> > all the way down into stringobject.c, no dice.  Then I noticed that the
> > failure is exactly what you get if the test was updated but the old
> > module wasn't.
> >
> > Faced with the choice of believing in a really strange platform specific
> > bug in a commonly used routine that resulted in exactly the failure caused
> > by one of the two files being updated or believing a failure occurred in the
> > long chain of networks, disks, file systems, build tools, and operating
> > systems that would result in only one of the files being updated -
> > I went with the latter.
> >
> > I'll continue in my belief until my dying day or until someone with OSX
> > confirms it is a bug, whichever comes first.
> >
> > not-gonna-sweat-it-ly,
> >
> > -Jack
> > ___
>
> OK, sorry for having caused you so much griefI'll investigate some
> more on the Pybots side and I'll let you know what I find.
>
> Grig
>


Actually, that test fails also in the official Python buildbot farm,
on a g4 osx machine. See

http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-test/0

So it looks like it's an OS X specific issue.

Grig
___
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

Re: [Python-Dev] New relative import issue

[Mark Hammond]

Guido writes:

> As Phillip understood, I meant the environment to include the
> filesystem (and on Windows, the registry -- in fact, Python on Windows
> *has* exactly such a mechanism in the registry, although I believe
> it's rarely used these days -- it was done by Mark Hammond to support
> COM servers I believe.)

It is rarely used these days due to the fact it is truly global to the
machine.  These days, it is not uncommon to have multiple copies of the same
Python version installed on the same box - generally installed privately
into an application by the vendor - eg, Komodo and Open Office both do this
to some degree.

The problem with a global registry is that *all* Python installations
honoured it.  This meant bugs in the vendor applications, as their 'import
foo' did *not* locate the foo module inside their directory, but instead
loaded a completely unrelated one, which promptly crashed.

A mechanism similar to .pth files, where the "declaration" of a module's
location is stored privately to the installation seems a more workable
approach.

Mark

___
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

Re: [Python-Dev] list.discard? (Re: dict.discard)

[skip]

Greg> Actually I'd like [discard] for lists.

It's obvious for sets and dictionaries that there is only one thing to
discard and that after the operation you're guaranteed the key no longer
exists.  Would you want the same semantics for lists or the semantics of
list.remove where it only removes the first instance?

When I want to remove something from a list I typically write:

   while x in somelist:
   somelist.remove(x)

not "if" as in your example.

Skip
___
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

Re: [Python-Dev] New relative import issue

[Josiah Carlson]

Greg Ewing <[EMAIL PROTECTED]> wrote:
> 
> Guido van Rossum wrote:
> 
> > Eek? If there are two third-party top-level packages A and B, by
> > different third parties, and A depends on B, how should A find B if
> > not via sys.path or something that is sufficiently equivalent as to
> > have the same problems?
> 
> Some kind of configuration mechanism is needed, but
> I don't see why it can't be a static, declarative one
> rather than computed at run time.

I could be missing something, or be completely off-topic, but why not
both, or really a mechanism to define:
1. Installation time package location (register package X in the package
registry at path Y and persist across Python sessions).
2. Runtime package location (package X is in path Y, do not persist
across Python sessions).

With 1 and 2, we remove the need for .pth files, all packages to be
installed into Lib/site-packages, and sys.path manipulation.  You want
access to package X?
packages.register('X', '~/mypackages/X')
packages.register('X', '~/mypackages/X', persist=True)
packages.register('X', '~/mypackages/X', systemwide=True)


This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python 2.5).  There can be a system-wide database that all users use as
a base, with a user-defined package registry (per user) where the
system-wide packages can be augmented.

With a little work, it could even be possible to define importers during
registration (filesystem, zip, database, etc.) or include a tracing
mechanism for py2exe/distutils/py2app/cx_freeze/etc. (optionally writing
to a simplified database-like file for distribution so that SQLite
doesn't need to be shipped).


 - Josiah

___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Martin v. Löwis]

Jack Diederich schrieb:
> Faced with the choice of believing in a really strange platform specific 
> bug in a commonly used routine that resulted in exactly the failure caused 
> by one of the two files being updated or believing a failure occurred in the
> long chain of networks, disks, file systems, build tools, and operating 
> systems that would result in only one of the files being updated -
> I went with the latter.

Please reconsider how subversion works. It has the notion of atomic
commits, so you either get the entire change, or none at all.

Fortunately, the buildbot keeps logs of everything it does:

http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-svn/0

shows

ULib/test/test_itertools.py
UModules/itertoolsmodule.c
Updated to revision 51950.

So it said it updated both files. But perhaps it didn't build them?
Let's check:


http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-compile/0

has this:

building 'itertools' extension

gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -g -Wall -Wstrict-prototypes -I.
-I/Users/buildslave/bb/trunk.psf-g4/build/./Include
-I/Users/buildslave/bb/trunk.psf-g4/build/./Mac/Include -I./Include -I.
-I/usr/local/include -I/Users/buildslave/bb/trunk.psf-g4/build/Include
-I/Users/buildslave/bb/trunk.psf-g4/build -c
/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.c -o
build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o

gcc -bundle -undefined dynamic_lookup
build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
-L/usr/local/lib -o build/lib.macosx-10.3-ppc-2.6/itertools.so

So itertools.so is regenerated, as it should; qed.

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

Re: [Python-Dev] New relative import issue

[Phillip J. Eby]

At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
>This can be implemented with a fairly simple package registry, contained
>within a (small) SQLite database (which is conveniently shipped in
>Python 2.5).  There can be a system-wide database that all users use as
>a base, with a user-defined package registry (per user) where the
>system-wide packages can be augmented.

As far as I can tell, you're ignoring that per-user must *also* be 
per-version, and per-application.  Each application or runtime environment 
needs its own private set of information like this.

Next, putting the installation data inside a database instead of 
per-installation-unit files presents problems of its own.  While some 
system packaging tools allow install/uninstall scripts to run, they are 
often frowned upon, and can be unintentionally bypassed.

These are just a few of the issues that come to mind.  Realistically 
speaking, .pth files are currently the most effective mechanism we have, 
and there actually isn't much that can be done to improve upon them.

What's more needed are better mechanisms for creating and managing Python 
"environments" (to use a term coined by Ian Bicking and Jim Fulton over on 
the distutils-sig), which are individual contexts in which Python 
applications run.  Some current tools in development by Ian and Jim include:

  http://cheeseshop.python.org/pypi/workingenv.py/
  http://cheeseshop.python.org/pypi/zc.buildout/

I don't know that much about either, but I do know that for zc.buildout, 
Jim's goal was to be able to install Python scripts with pre-baked sys.path 
based on package dependencies from setuptools, and as far as I know, he 
achieved it.

Anyway, system-wide and per-user environment information isn't nearly 
sufficient to address the issues that people have when developing and 
deploying multiple applications on a server, or even using multiple 
applications on a client installation (e.g. somebody using both the 
Enthought Python IDE and Chandler on the same machine).  These relatively 
simple use cases rapidly demonstrate the inadequacy of system-wide or 
per-user configuration of what packages are available.

___
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

Re: [Python-Dev] New relative import issue

[Steve Holden]

Paul Moore wrote:
> On 9/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 
>>I think one missing feature is a mechanism whereby you can say "THIS
>>package (gives top-level package name) lives HERE (gives filesystem
>>location of package)" without adding the parent of HERE to sys.path
>>for all module searches. I think Phillip Eby's egg system might
>>benefit from this.
> 
> 
> This is pretty easy to do with a custom importer on sys.meta_path.
> Getting the details right is a touch fiddly, but it's conceptually
> straightforward.
> 
> Hmm, I might play with this - a set of PEP 302 importers to completely
> customise the import mechanism. The never-completed "phase 2" of the
> PEP included a reimplementation of the built in import mechanism as
> hooks. Is there any interest in this actually happening? I've been
> looking for an interesting coding project for a while (although I
> never have any free time...)
> 
My interest in such a project would be in replacing a bunch of legacy C 
code with varying implementations of the import mechanism in pure Python 
strictly according to the dictats of PEP 302, using sys.path_hooks and 
sys.path (meta_path is for future consideration ;-).

Some readers may remember a lightning talk I gave at OSCON about three 
years ago. In that I discussed a database structure that allowed 
different implementations of modules to be loaded according to 
compatibility requirements established as a result of testing.

Although I now have a working database import mechanism based on PEP 302 
it's by no means obvious how that can be used exclusively (in other 
words, replacing the current import mechanism: the present 
implementation relies on an import of MySQLdb, which has many 
dependencies that clearly must be importable before the DB mechanism is 
in place). And I certainly haven't followed up by establishing the 
compatibility data that such an implementation would require.

Has anyone done any work on (for example) zip-only distributions?

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb   http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

___
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

Re: [Python-Dev] list.discard? (Re: dict.discard)

[Steve Holden]

Fred L. Drake, Jr. wrote:
> On Thursday 21 September 2006 20:21, Greg Ewing wrote:
>  >if x not in somelist:
>  >  somelist.remove(x)
> 
> I'm just guessing you really meant "if x in somelist".  ;-)
> 
No you aren't, that's clearly an *informed* guess.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb   http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Fri, Sep 22, 2006 at 06:09:41AM +0200, "Martin v. L?wis" wrote:
> Jack Diederich schrieb:
> > Faced with the choice of believing in a really strange platform specific 
> > bug in a commonly used routine that resulted in exactly the failure caused 
> > by one of the two files being updated or believing a failure occurred in the
> > long chain of networks, disks, file systems, build tools, and operating 
> > systems that would result in only one of the files being updated -
> > I went with the latter.
> 
> Please reconsider how subversion works. It has the notion of atomic
> commits, so you either get the entire change, or none at all.
> 
> Fortunately, the buildbot keeps logs of everything it does:
> 
> http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-svn/0
> 
> shows
> 
> ULib/test/test_itertools.py
> UModules/itertoolsmodule.c
> Updated to revision 51950.
> 
> So it said it updated both files. But perhaps it didn't build them?
> Let's check:
> 
> 
> http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-compile/0
> 
> has this:
> 
> building 'itertools' extension
> 
> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
> -mno-fused-madd -g -Wall -Wstrict-prototypes -I.
> -I/Users/buildslave/bb/trunk.psf-g4/build/./Include
> -I/Users/buildslave/bb/trunk.psf-g4/build/./Mac/Include -I./Include -I.
> -I/usr/local/include -I/Users/buildslave/bb/trunk.psf-g4/build/Include
> -I/Users/buildslave/bb/trunk.psf-g4/build -c
> /Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.c -o
> build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
> 
> gcc -bundle -undefined dynamic_lookup
> build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
> -L/usr/local/lib -o build/lib.macosx-10.3-ppc-2.6/itertools.so
> 
> So itertools.so is regenerated, as it should; qed.
> 

I should leave the tounge-in-cheek bombast to Tim and Frederik, especially
when dealing with what might be an OS & machine specific bug.  The next
checkin and re-test will or won't highlight a failure and certainly someone 
with a g4 will try it out before 2.5.1 goes out so we'll know if it was a 
fluke soonish. The original error was mine, I typed "Size_t" instead of 
"Ssize_t" and while my one-char patch might also be wrong (I hope not, I'm 
red-faced enough as is) we should find out soon enough.

-Jack
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Neal Norwitz]

On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
>
> I should leave the tounge-in-cheek bombast to Tim and Frederik, especially
> when dealing with what might be an OS & machine specific bug.  The next
> checkin and re-test will or won't highlight a failure and certainly someone
> with a g4 will try it out before 2.5.1 goes out so we'll know if it was a
> fluke soonish. The original error was mine, I typed "Size_t" instead of
> "Ssize_t" and while my one-char patch might also be wrong (I hope not, I'm
> red-faced enough as is) we should find out soon enough.

It looks like %zd of a negative number is treated as an unsigned
number on OS X, even though the man page says it should be signed.

"""
The z modifier, when applied to a d or i conversion, indicates that
the argument is of a signed type equivalent in size to a size_t.
"""

The program below returns -123 on Linux and 4294967173 on OS X.

n
--
#include 
int main()
{
char buffer[256];
  if(sprintf(buffer, "%zd", (size_t)-123) < 0)
return 1;
 printf("%s\n", buffer);
 return 0;
}
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Tim Peters]

[Neal Norwitz]
> It looks like %zd of a negative number is treated as an unsigned
> number on OS X, even though the man page says it should be signed.
>
> """
> The z modifier, when applied to a d or i conversion, indicates that
> the argument is of a signed type equivalent in size to a size_t.
> """

It's not just some man page ;-), this is required by the C99 standard
(which introduced the `z` length modifier -- and it's the `d` or `i`
here that imply `signed`, `z` is only supposed to specify the width of
the integer type, and can also be applied to codes for unsigned
integer types, like %zu and %zx).

> The program below returns -123 on Linux and 4294967173 on OS X.
>
> n
> --
> #include 
> int main()
> {
> char buffer[256];
>   if(sprintf(buffer, "%zd", (size_t)-123) < 0)
> return 1;
>  printf("%s\n", buffer);
>  return 0;
> }

Well, to be strictly anal, while the result of

(size_t)-123

is defined, the result of casting /that/ back to a signed type of the
same width is not defined.  Maybe your compiler was "doing you a
favor" ;-)
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Thu, Sep 21, 2006 at 10:23:54PM -0700, Neal Norwitz wrote:
> On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> >
> > I should leave the tounge-in-cheek bombast to Tim and Frederik, especially
> > when dealing with what might be an OS & machine specific bug.  The next
> > checkin and re-test will or won't highlight a failure and certainly someone
> > with a g4 will try it out before 2.5.1 goes out so we'll know if it was a
> > fluke soonish. The original error was mine, I typed "Size_t" instead of
> > "Ssize_t" and while my one-char patch might also be wrong (I hope not, I'm
> > red-faced enough as is) we should find out soon enough.
> 
> It looks like %zd of a negative number is treated as an unsigned
> number on OS X, even though the man page says it should be signed.
> 
> """
> The z modifier, when applied to a d or i conversion, indicates that
> the argument is of a signed type equivalent in size to a size_t.
> """
> 
> The program below returns -123 on Linux and 4294967173 on OS X.
> 
> n
> --
> #include 
> int main()
> {
> char buffer[256];
>   if(sprintf(buffer, "%zd", (size_t)-123) < 0)
> return 1;
>  printf("%s\n", buffer);
>  return 0;
> }

Consider me blushing even harder for denying the power of the buildbot
(and against all evidence).  Yikes, didn't any other tests trigger this?

sprat:~/src/python-head# find ./ -name '*.c' | xargs grep '%zd' | wc -l
65

-Jack
___
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

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Neal Norwitz]

On 9/21/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Well, to be strictly anal, while the result of
>
> (size_t)-123
>
> is defined, the result of casting /that/ back to a signed type of the
> same width is not defined.  Maybe your compiler was "doing you a
> favor" ;-)

I also tried with a cast to an ssize_t and replacing %zd with an %zi.
None of them make a difference; all return an unsigned value.  This is
with powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple
Computer, Inc. build 4061).  Although i would expect the issue is in
the std C library rather than the compiler.

Forcing PY_FORMAT_SIZE_T to be "l" instead of "z" fixes this problem.

BTW, this is the same issue on Mac OS X:

>>> struct.pack('=b', -59)
__main__:1: DeprecationWarning: 'b' format requires 4294967168 <= number <= 127
'A'

n
--
___
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