Re: [Python-Dev] summary of transitioning from % to {} formatting

[Nick Coghlan]

Vinay Sajip wrote:
> Both of these approaches will also work for {}-formatting. The present thread
> really started out with a view to suggesting that the stdlib start adopting
> {}-format as "native", rather than %-format.
> 
> Would it be helpful if I added a section to the Python docs about how to use
> alternative formatting systems with logging?

That would probably be a good idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Help needed for tar archive creation with changed UID/GID

[bheemesh v]

Hello,

I am a newbie to this mailing list, i have seen in some mail discussions
about a tar archive creation by forcibly setting the UID/GID to a specific
user (say root).

Te code mentioned goes like this:

tar = tarfile.open("foo.tar.gz", "w:gz")
for filename in filenames:
  tarinfo = tar.gettarinfo(filename)
  if tarinfo.isreg():
fobj = open(filename)
  else:
fobj = None

  tarinfo.uid = 0
  tarinfo.gid = 0
  tar.addfile(tarinfo, fobj)
tar.close()

But this is not really working for me as when i am trying to un-tar or
un-compress contents to a new directory and contents still have diff GID &
UID in the long listing of directory.

Can somebody suggest an alternative or a working case if already changes are
done here.

Thanks in advance.

Best regards,
Bheemesh
___
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] Help needed for tar archive creation with changed UID/GID

[Stefan Behnel]

bheemesh v wrote:
> I am a newbie to this mailing list, i have seen in some mail discussions
> about a tar archive creation by forcibly setting the UID/GID to a specific
> user (say root).

Note that this is the mailing list about core development of the CPython
interpreter, not about general Python development.

Please refer your request to python-l...@python.org or tu...@python.org
instead.

Stefan

___
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] Help needed for tar archive creation with changed UID/GID

[Michael Foord]

bheemesh v wrote:

Hello,

I am a newbie to this mailing list, i have seen in some mail 
discussions about a tar archive creation by forcibly setting the 
UID/GID to a specific user (say root).


Hello Bheemesh,

This mailing list is for the development of Python, not for developing 
*with* Python. There are other more appropriate mailing lists where you 
will hopefully get helpful answers:



The Python tutor list
http://mail.python.org/mailman/listinfo/tutor

The comp.lang.python newsgroup
The email gateway: http://mail.python.org/mailman/listinfo/python-list
A google groups interface: 
http://groups.google.com/group/comp.lang.python/topics?lnk=li&hl=en&pli=1


All the best,

Michael Foord




Te code mentioned goes like this:
tar = tarfile.open("foo.tar.gz", "w:gz")
for filename in filenames:
  tarinfo = tar.gettarinfo(filename)
  if tarinfo.isreg():
fobj = open(filename)
  else:
fobj = None


  tarinfo.uid = 0
  tarinfo.gid = 0
  tar.addfile(tarinfo, fobj)
tar.close()
  
But this is not really working for me as when i am trying to un-tar or 
un-compress contents to a new directory and contents still have diff 
GID & UID in the long listing of directory.


Can somebody suggest an alternative or a working case if already 
changes are done here.


Thanks in advance.

Best regards,
Bheemesh


___
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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.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] Package install failures in 2.6.3

[David Cournapeau]

2009/10/6 P.J. Eby :
> At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote:
>>
>> Setuptools development has been discontinued for a year, and does
>> patches on Distutils code. Some of these patches are sensitive to any
>> change
>> made on Distutils, wether those changes are internal or not.
>
> Setuptools is  also not the only thing out there that subclasses distutils
> commands in general, or the build_ext command in particular.  Numpy,
> Twisted, the mx extensions...  there are plenty of things out there that
> subclass distutils commands, quite in adherence to the rules.  (Note too
> that subclassing != patching, and the ability to subclass and substitute
> distutils commands is documented.)
>
> It's therefore not appropriate to treat the issue as if it were
> setuptools-specific; it could have broken any other major (or minor)
> package's subclassing of the build_ext command.

The internal vs published API difference does not make much sense in
distutils case anyway, since a lot of implementation details are
necessary to make non trivial extension work.

When working on numpy.distutils, I almost always have to look at
distutils sources since the docs are vastly insufficient, and even
then, the code is so bad that quite often the only way to interact
with distutils is to "reverse engineer" its behavior by trial and
error.

cheers,

David
___
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] eggs now mandatory for pypi?

[Chris Withers]

Nick Coghlan wrote:

Really? I can understand package owners not being able to add
recommendations for their own packages, but if they can't add comments
how are they meant to correct misunderstandings or redirect
inappropriate messages to the correct forums?


Indeed, yet another reason I would like to have the option to disable 
comments for my packages. I make sure there are advertised mailing lists 
available for all my packages, and they are all much for featureful than 
PyPI should ever hope to be...


https://sourceforge.net/tracker/?func=detail&aid=2872293&group_id=66150&atid=513503

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] eggs now mandatory for pypi?

[Chris Withers]

M.-A. Lemburg wrote:

We've implemented our own bdist_egg now which doesn't use setuptools
and will start to ship eggs in addition to our prebuilt format with
the next releases.


Egg-cellent ;-)

Any chance this tool is open source? Better yet, could it make its way 
into distutils asap?


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] eggs now mandatory for pypi?

[Chris Withers]

Fredrik Lundh wrote:

Oh, it was just yet another Zope developer behaving like an ass.  Why
am I not surprised?


Actually Plohn, there aren't that many Zope developers left ;-)

Chris - looking mournfully at his sig...

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] "PIL" vs. "Imaging" (was Re: eggs now mandatory for pypi?)

[Chris Withers]

Fredrik Lundh wrote:

Looks like the quickest fix is to distribute two source packages, one
built the traditional way to eliminate breakage for people using the
current tarball layout, and one built with "sdist".


Why the need for two?

Or, asked differently, who would be hurt if the distribution name became 
PIL? (distribution name != package names in distribution)


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] Package install failures in 2.6.3

[Chris Withers]

Tarek Ziadé wrote:

Notice that I am also doing nightly builds of Distutils that can be installed
and tried in released version of Python, and that can be used instead of the
Python's embed Distutils  (see the installable tarballs at nightly.ziade.org).
so maybe it's just a matter of continuous integration


Could these be released as normal sdist packages on PyPI?
That would seem the best way to get them used...

(bonus points for working with buildout,virtualenv,pip,etc)

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] eggs now mandatory for pypi?

[M.-A. Lemburg]

Chris Withers wrote:
> M.-A. Lemburg wrote:
>> We've implemented our own bdist_egg now which doesn't use setuptools
>> and will start to ship eggs in addition to our prebuilt format with
>> the next releases.
> 
> Egg-cellent ;-)
> 
> Any chance this tool is open source? Better yet, could it make its way
> into distutils asap?

mxSetup.py, the module implementing all our distutils extensions,
is available in egenix-mx-base which is open source:

http://www.egenix.com/products/python/mxBase/

Here's current snapshot:

http://downloads.egenix.com/python/egenix-mx-base-3.2.0_20091006.zip

or as egg

http://downloads.egenix.com/python/egenix_mx_base-3.2.0_20091006-py2.6-linux-x86_64.egg

Note how the package name is mangled... easy_install requires this.
The file name also doesn't tell you that the above is for
a UCS2 Python build. Again, easy_install fails with that information
added to the "py2.6" version marker.

We're still tweaking the implementation a bit, but it's stabilizing
rather quickly.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] Package install failures in 2.6.3

[Chris Withers]

Barry Warsaw wrote:

2) PJE releases a new version of setuptools that fixes this problem.

3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g. 
on cheeseshop) and releases a new version


It's a shame you didn't suggest this sooner. It would have avoided the 
need for the seperate Distribute project and all the horrible hacks it 
entails for every package that uses setuptools...


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] eggs now mandatory for pypi?

[Chris Withers]

M.-A. Lemburg wrote:

mxSetup.py, the module implementing all our distutils extensions,
is available in egenix-mx-base which is open source:

http://www.egenix.com/products/python/mxBase/


I have memories of mxBase having a load of other stuff in it too?

Would it be possible to split just the distutils extensions into their 
own package and get that package as an sdist on PyPI?


That said, I still think getting the bdist_egg code, at least, into 
Distutils in the core as soon as possible would be a very good thing. 
It's kinda odd having the python equivalent of jars or gems only being 
created by third party software that's no longer maintained...


> Note how the package name is mangled... easy_install requires this.
> The file name also doesn't tell you that the above is for
> a UCS2 Python build. Again, easy_install fails with that information
> added to the "py2.6" version marker.

Surely this stuff all belongs in the static metadata file that keeps on 
overcomplicating itself in discussions?


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] a new setuptools release?

[Chris Withers]

Hi Phil,

It's almost a week since I made this offer. I haven't heard anything 
from you. If I've missed anything please let me know and I'll track it 
down, otherwise I hope you can have a look at this some time soon.


cheers,

Chris

Chris Withers wrote:

P.J. Eby wrote:
Here's what actually happened, if anyone cares.  Tarek and friends 
announced a fork of setuptools.  I reviewed the work and saw that -- 
for the most part -- I was happy with it, and opined as how I might be 
willing to bless the the "package inquisition" team as official 
maintainers of the 0.6 branch of setuptools, so that I could work on 
the fun bits I've long planned for 0.7, but never felt free to start 
on while there was so much still needing to be done on 0.6.


If this offer is still available, I'd lake to take you up on it.
I'd be more than willing to merge changes on the 0.6 distribute branch 
back into the setuptools codebase and do whatever is needed to get a new 
setuptools release out.


Why? Because there are a *lot* of copies of ez_setup.py and buildout's 
bootstrap.py that will need replacing if it doesn't happen. I think it'd 
be better for the python community all round if setuptools just 
continued in maintenance mode until whatever-ends-up-in-the-core exists 
and people want to use...


I'm happy to submit to whatever supervision is needed for you to trust 
me to do this, and I promise to be as careful as I can with this. I 
*know* how important this is and want to make it work...


All I want is for good stuff to happen for setuptools users and Python 
users in general, so I don't think all the suspicion and backbiting is 
merited. 


Fine, if that's true, I apologize (even spelled correctly!) for any 
previous involvement in this, but please help me help you achieve your 
aims...


To put this into a way that makes sense to me: I'm volunteering to keep 
distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and 
keep that as uncontroversial as possible, and get setuptools 0.6 
releases out to match distribute 0.6 releases as soon as I can.


Again, I feel I need to stress that the *only* reason I want to do this 
is to bring the benefits of the distribute work to the existing 
setuptools codebase, with appropriate attribution if that makes a 
difference.


Apologies if any of this is offensive to anyone. For once (really!) I 
really mean that :-)


cheers,

Chris



--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[Ronald Oussoren]

On 3 Oct, 2009, at 1:40, INADA Naoki wrote:


Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.


OK.
`s = '\xa0'` should be `s = b'\xa0'`.

Should I file a bug?


Please do, that helps us remember that the issue exists.

Ronald



--
Naoki INADA  
___
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/ronaldoussoren%40mac.com




smime.p7s
Description: S/MIME cryptographic signature
___
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] eggs now mandatory for pypi?

[Arc Riley]

I'll make the argument that feedback is useful, comments are much less so
and a lot more work.

It would be more useful to allow package users post feedback, visible only
to the package maintainer, and also add support for bugtracker links/etc.

Is the intention of Pypi really to turn it into a social networking site?
___
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] eggs now mandatory for pypi?

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 5:11 PM, M.-A. Lemburg  wrote:
> Senthil Kumaran wrote:
>> On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote:
>>> it's revews like this that makes me wonder if releasing open source is
>>> a good idea:
>>>    no egg - worst seen ever, remove it from pypi or provide an egg
>>> (jensens, 2009-10-05, 0 points)
>>>
>>
>> Greetings effbot. :)
>> As you might already know, "eggs" are not mandatory for pypi. No where
>> in the documentation it mentions so. Also many good packages in pypi
>> are not eggs (MaL's egenix packages for e.g) and we have known his
>> dislike for that particular format too.
>
> I don't dislike the format itself, just the tools that are
> available for using it.
>
> We've implemented our own bdist_egg now which doesn't use setuptools
> and will start to ship eggs in addition to our prebuilt format with
> the next releases.
>
> As time permits, we'll also write an egg installer/uninstaller
> (one that does only that ;-).
>
>> But still, sometimes people have found eggs to be convenient.

The idea of PEP 376 we are working on is to have a unique unified
standard for distributions
installed in site-packages, instead of the current situation where we
have many installation formats.
(Distutils pre-Python 2.5, Distutils post-Python2.5, Setuptools
self-contained Eggs, ..)
because it makes it simple to provide APIs to query what's installed,
and ways to uninstall things.

That's what I would call the "Missing APIs" to make Distutils a
package manager, or at least a basis for package
managers.

Having an egg installer/uninstaller that works with Setuptools-like
self-contained eggs sounds like
a package manager system on its own and yet another format.

But as far as we went in the discussions for PEP 376, it seemed like a
first step would be to work with a single
installation format and provides all APIs for it, then to think about
having other formats and ways to query them
in a second move.

That's why I don't think its the right time to add a bdist_egg command
in Distutils, until PEP 376 is
fully defined (and maybe extended to support several format).

Tarek

-- 
Tarek Ziadé | http://ziade.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] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

[INADA Naoki]

I filed as issue7072.

On Tue, Oct 6, 2009 at 10:49 PM, Ronald Oussoren  wrote:
>
> On 3 Oct, 2009, at 1:40, INADA Naoki wrote:
>
>>> Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.
>>
>> OK.
>> `s = '\xa0'` should be `s = b'\xa0'`.
>>
>> Should I file a bug?
>
> Please do, that helps us remember that the issue exists.
>
> Ronald
>
>>
>> --
>> Naoki INADA  
>> ___
>> 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/ronaldoussoren%40mac.com
>
>



-- 
Naoki INADA  
___
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] eggs now mandatory for pypi?

[M.-A. Lemburg]

Chris Withers wrote:
> M.-A. Lemburg wrote:
>> mxSetup.py, the module implementing all our distutils extensions,
>> is available in egenix-mx-base which is open source:
>>
>> http://www.egenix.com/products/python/mxBase/
> 
> I have memories of mxBase having a load of other stuff in it too?

Yep, lots of it.

> Would it be possible to split just the distutils extensions into their
> own package and get that package as an sdist on PyPI?

Nope. The main reason for having switched to distributions is
to make things easier to manage - both for us and our users.

> That said, I still think getting the bdist_egg code, at least, into
> Distutils in the core as soon as possible would be a very good thing.
> It's kinda odd having the python equivalent of jars or gems only being
> created by third party software that's no longer maintained...
> 
>> Note how the package name is mangled... easy_install requires this.
>> The file name also doesn't tell you that the above is for
>> a UCS2 Python build. Again, easy_install fails with that information
>> added to the "py2.6" version marker.
> 
> Surely this stuff all belongs in the static metadata file that keeps on
> overcomplicating itself in discussions?

The complicated stuff does belong somewhere else, but the
basic things need to go into the filename - simply because
you have to build separate files for each Python build
dimension and want to be able to put everything into
a single directory or index:

 * Python version
 * Architecture/Platform
 * UCS2/UCS4

E.g. to solve the UCS2/4 part, we had to setup separate
PyPI-style index sites. We'd really like to avoid that if
possible.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] eggs now mandatory for pypi?

[Chris Withers]

M.-A. Lemburg wrote:

Would it be possible to split just the distutils extensions into their
own package and get that package as an sdist on PyPI?


Nope. 


shame :-(


The complicated stuff does belong somewhere else, but the
basic things need to go into the filename 


But everyone's basic things are different.



- simply because
you have to build separate files for each Python build
dimension and want to be able to put everything into
a single directory or index:

 * Python version
 * Architecture/Platform
 * UCS2/UCS4

E.g. to solve the UCS2/4 part, we had to setup separate
PyPI-style index sites. We'd really like to avoid that if
possible.


Well yeah, and the only sane way I can think to handle this is to have a 
metadata file that gets uploaded with each distribution that covers all 
these things (and the other things that other people need) and then have 
the index (which would hopefully be PyPI on the whole) be queryable 
along the lines of "give me a download url for a distribution named X 
that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"...


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] eggs now mandatory for pypi?

[M.-A. Lemburg]

Chris Withers wrote:
> M.-A. Lemburg wrote:
>> The complicated stuff does belong somewhere else, but the
>> basic things need to go into the filename 
> 
> But everyone's basic things are different.

The really basic stuff is the same for everyone since it's
dictated by the way Python works on computers :-)

>> - simply because
>> you have to build separate files for each Python build
>> dimension and want to be able to put everything into
>> a single directory or index:
>>
>>  * Python version
>>  * Architecture/Platform
>>  * UCS2/UCS4
>>
>> E.g. to solve the UCS2/4 part, we had to setup separate
>> PyPI-style index sites. We'd really like to avoid that if
>> possible.
> 
> Well yeah, and the only sane way I can think to handle this is to have a
> metadata file that gets uploaded with each distribution that covers all
> these things (and the other things that other people need) and then have
> the index (which would hopefully be PyPI on the whole) be queryable
> along the lines of "give me a download url for a distribution named X
> that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"...

So you want the indirection to happen even before fetching
the download package ?

That's a good idea - and also a lot better than the web page
link scanning that setuptools is doing.

It goes a bit in the direction of what we had in mind with writing
for our clients: a tool that looks at the Python installation and
automatically finds/downloads/installs the right package from
our website. Only that we wanted to put up a single index file
for that tool to use, not one per package.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] eggs now mandatory for pypi?

[P.J. Eby]

At 03:18 PM 10/6/2009 +0200, M.-A. Lemburg wrote:

Note how the package name is mangled... easy_install requires this.
The file name also doesn't tell you that the above is for
a UCS2 Python build. Again, easy_install fails with that information
added to the "py2.6" version marker.


Btw, every couple years or so I've sent out a call on the 
distutils-SIG to try to get consensus on a format for the platform 
tag information used by setuptools.  (The first time was before 
easy_install even existed.)  Unfortunately, it's rare that anybody 
contributes more than criticism of the existing scheme.  The last 
updates to the scheme were by Mac folks, who at least had a clear 
vision of what was needed.  There's been some win32/win64 discussion 
in the past, but no proposals or patches of comparable 
specificity.  Linux and other unices haven't had any concrete 
suggestions at all, AFAICR.


Anyway...  just saying that if you *have* a concretely implementable 
proposal about what to do with platform tags, please do share on the 
distutils-sig.  Platform tags are one area that's reasonably easy to 
upgrade in a backward-compatible-ish way; newer versions of 
easy_install can still recognize older tags, although new eggs won't 
be recognized by older installers (forcing people to upgrade 
setuptools in that case).


___
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] a new setuptools release?

[P.J. Eby]

At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:
To put this into a way that makes sense to me: I'm volunteering to 
keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, 
and try and keep that as uncontroversial as possible, and get 
setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.


That may not be as easy as it sounds; Distribute deleted various 
things from the setuptools tree (e.g. the release.sh script, used for 
issuing releases) and of course it adds other stuff (e.g. stuff to 
overwrite setuptools).  So you'd need to screen the diffs.


Second, I still intend to move setuptools 0.7 forward at some point, 
which means the patches also need to go to the trunk.


If I had the time to co-ordinate and supervise all this, I'd have the 
time to just do it myself.


If you want to help with that, the most helpful thing would be for 
you to consolidate all the changes into a pair of patches: one for 
the 0.6 branch and one for the 0.7 trunk.


These patches would also need to exclude the SVN 1.6 changes (as I 
already have a change for that in my working copy, not yet checked 
in).  They would also need to include appropriate changelog and 
documentation updates.


If you can get those to me by Friday, I'll have them reviewed, 
applied, and released by Monday.  I was already planning to spend a 
little time on bug closing and patch application this coming weekend, 
so if you can do this for me first, it will maximize the number I can get done.


___
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] eggs now mandatory for pypi?

[P.J. Eby]

At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote:

Chris Withers wrote:
> Well yeah, and the only sane way I can think to handle this is to have a
> metadata file that gets uploaded with each distribution that covers all
> these things (and the other things that other people need) and then have
> the index (which would hopefully be PyPI on the whole) be queryable
> along the lines of "give me a download url for a distribution named X
> that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"...

So you want the indirection to happen even before fetching
the download package ?

That's a good idea - and also a lot better than the web page
link scanning that setuptools is doing.


They're not mutually exclusive, btw.  More information could be added 
to the PyPI "Simple" API to include this sort of thing, visible to 
newer installers and invisible to older ones.


The main reason why easy_install has a relatively simple, REST 
outgoing API is that it allows people to make their own compatible 
indexes just by throwing some files in a directory and turning on 
Apache directory indexing.  By using a... what do they call it, 
"microformat"? to mark up other information in the file, it'd still 
be possible for someone to slap up a web page and use it as a package index.




It goes a bit in the direction of what we had in mind with writing
for our clients: a tool that looks at the Python installation and
automatically finds/downloads/installs the right package from
our website. Only that we wanted to put up a single index file
for that tool to use, not one per package.


That'd get a bit big for PyPI, though, with thousands of listed 
packages.  It's already pretty slow whenever somebody miscapitalizes 
or mis-punctuates a package name and easy_install has to read the 
"file" that just lists all the package names.  That, of course, is 
more a function of the fact that PyPI's "simple" API doesn't support 
canonicalization, although I believe certain other PyPI-mirroring and 
package indexing apps do.


___
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] eggs now mandatory for pypi?

[M.-A. Lemburg]

P.J. Eby wrote:
> At 03:18 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
>> Note how the package name is mangled... easy_install requires this.
>> The file name also doesn't tell you that the above is for
>> a UCS2 Python build. Again, easy_install fails with that information
>> added to the "py2.6" version marker.
> 
> Btw, every couple years or so I've sent out a call on the distutils-SIG
> to try to get consensus on a format for the platform tag information
> used by setuptools.  (The first time was before easy_install even
> existed.)  Unfortunately, it's rare that anybody contributes more than
> criticism of the existing scheme.  The last updates to the scheme were
> by Mac folks, who at least had a clear vision of what was needed. 
> There's been some win32/win64 discussion in the past, but no proposals
> or patches of comparable specificity.  Linux and other unices haven't
> had any concrete suggestions at all, AFAICR.
> 
> Anyway...  just saying that if you *have* a concretely implementable
> proposal about what to do with platform tags, please do share on the
> distutils-sig.  Platform tags are one area that's reasonably easy to
> upgrade in a backward-compatible-ish way; newer versions of easy_install
> can still recognize older tags, although new eggs won't be recognized by
> older installers (forcing people to upgrade setuptools in that case).

Here's a very simple Python version scheme we've been using
for years:

pyX.X_ucsY

with X.X being the major.minor Python version and Y being
either 2 or 4 depending on the UCS-build that was used to
build the egg.

The "_ucsY" part is not needed for pure-Python archives (but it
doesn't hurt using it there as well) and also not needed on
Windows, since Python is always UCS2 on Windows.

easy_install should first look for the full version string and
then fall back to the non-UCS one.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] a new setuptools release?

[Guido van Rossum]

On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby  wrote:
> At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:
>>>
>>> To put this into a way that makes sense to me: I'm volunteering to keep
>>> distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and
>>> keep that as uncontroversial as possible, and get setuptools 0.6 releases
>>> out to match distribute 0.6 releases as soon as I can.
>
> That may not be as easy as it sounds; Distribute deleted various things from
> the setuptools tree (e.g. the release.sh script, used for issuing releases)
> and of course it adds other stuff (e.g. stuff to overwrite setuptools).  So
> you'd need to screen the diffs.
>
> Second, I still intend to move setuptools 0.7 forward at some point, which
> means the patches also need to go to the trunk.

Dream on.

> If I had the time to co-ordinate and supervise all this, I'd have the time
> to just do it myself.

I think at this point the community should not be forced wait for you
to get a new supply of round tuits. The wait has been too long
already. You can stay on in an advisory role, but I don't think it's
reasonable to block development or decisions until you have time.

> If you want to help with that, the most helpful thing would be for you to
> consolidate all the changes into a pair of patches: one for the 0.6 branch
> and one for the 0.7 trunk.
>
> These patches would also need to exclude the SVN 1.6 changes (as I already
> have a change for that in my working copy, not yet checked in).  They would
> also need to include appropriate changelog and documentation updates.
>
> If you can get those to me by Friday, I'll have them reviewed, applied, and
> released by Monday.  I was already planning to spend a little time on bug
> closing and patch application this coming weekend, so if you can do this for
> me first, it will maximize the number I can get done.

That's great, but I don't think it solves the structural problem,
which is that you don't have enough time to devote to the project.

-- 
--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] a new setuptools release?

[Olemis Lang]

On Tue, Oct 6, 2009 at 2:16 PM, Guido van Rossum  wrote:
> On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby  wrote:
>> At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:

 To put this into a way that makes sense to me: I'm volunteering to keep
 distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and
 keep that as uncontroversial as possible, and get setuptools 0.6 releases
 out to match distribute 0.6 releases as soon as I can.
>>
>> That may not be as easy as it sounds; Distribute deleted various things from
>> the setuptools tree (e.g. the release.sh script, used for issuing releases)
>> and of course it adds other stuff (e.g. stuff to overwrite setuptools).  So
>> you'd need to screen the diffs.
>>
>> Second, I still intend to move setuptools 0.7 forward at some point, which
>> means the patches also need to go to the trunk.
>
> Dream on.
>
>> If I had the time to co-ordinate and supervise all this, I'd have the time
>> to just do it myself.
>
> I think at this point the community should not be forced wait for you
> to get a new supply of round tuits. The wait has been too long
> already. You can stay on in an advisory role, but I don't think it's
> reasonable to block development or decisions until you have time.
>

Is it possible to fork `setuptools` somehow ? This way :

  - patches may be built for setuptools 0.7 if it evolves
  - community can continue development in the «new» branch.

all this easy if a DVCS is used ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
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] a new setuptools release?

[Ronald Oussoren]

On 6 Oct, 2009, at 21:56, Olemis Lang wrote:



Is it possible to fork `setuptools` somehow ? This way :


Yes, see 

Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
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] a new setuptools release?

[P.J. Eby]

At 12:16 PM 10/6/2009 -0700, Guido van Rossum wrote:

I think at this point the community should not be forced wait for you
to get a new supply of round tuits. The wait has been too long
already. You can stay on in an advisory role, but I don't think it's
reasonable to block development or decisions until you have time.


Tarek didn't think so either, which is why he created a fork, called 
Distribute.  So I'm not really clear on what you're trying to say 
here (or in the rest of the email, for that matter).


___
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] a new setuptools release?

[Guido van Rossum]

I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for setuptools 0.7.

On Tue, Oct 6, 2009 at 1:08 PM, P.J. Eby  wrote:
> At 12:16 PM 10/6/2009 -0700, Guido van Rossum wrote:
>>
>> I think at this point the community should not be forced wait for you
>> to get a new supply of round tuits. The wait has been too long
>> already. You can stay on in an advisory role, but I don't think it's
>> reasonable to block development or decisions until you have time.
>
> Tarek didn't think so either, which is why he created a fork, called
> Distribute.  So I'm not really clear on what you're trying to say here (or
> in the rest of the email, for that matter).
>
>



-- 
--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] eggs now mandatory for pypi?

[M.-A. Lemburg]

P.J. Eby wrote:
> At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
>> It goes a bit in the direction of what we had in mind with writing
>> for our clients: a tool that looks at the Python installation and
>> automatically finds/downloads/installs the right package from
>> our website. Only that we wanted to put up a single index file
>> for that tool to use, not one per package.
> 
> That'd get a bit big for PyPI, though, with thousands of listed
> packages.  It's already pretty slow whenever somebody miscapitalizes or
> mis-punctuates a package name and easy_install has to read the "file"
> that just lists all the package names.  That, of course, is more a
> function of the fact that PyPI's "simple" API doesn't support
> canonicalization, although I believe certain other PyPI-mirroring and
> package indexing apps do.

The above was only meant for our eGenix packages, not PyPI.

For PyPI the natural answer to this is to use the already existing
PyPI XML-RPC interface:

http://wiki.python.org/moin/PyPiXmlRpc

This would only have to grow a few more fields for the release
downloads in order to be able to match the user's Python configuration
to the available release downloads.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Zooko O'Whielacronx]

Here are three buildbot farms for three different projects that
exercise various features of setuptools: build, install, sdist_dsc,
bdist_egg, sdist, and various specific requirements that our projects
have, such as the "Desert Island Build" in which setuptools is not
allowed to download anything from the Internet at build time or else
it flunks the test.

http://allmydata.org/buildbot/waterfall
http://allmydata.org/buildbot-pycryptopp/waterfall
http://allmydata.org/buildbot-zfec/waterfall

I would love it if new versions of setuptools/Distribute would make
more of these tests pass on more platforms or at least avoid causing
any regressions in these tests on these platforms.

Unfortunately, we can't really deploy new versions of
setuptools/Distribute to this buildbot farm in order to re-run all the
tests, because the only way that I know of to trigger all the tests is
to make a commit to our central darcs repository for Tahoe-LAFS,
pycryptopp, or zfec, and I don't want to do that to experiment with
new versions of setuptools/Distribute.  Does anyone know how to use a
buildbot farm like this one to run tests without committing patches to
the central repository?

Regards,

Zooko
___
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] a new setuptools release?

[P.J. Eby]

At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:

suggest nobody hold their breath waiting for setuptools 0.7.


I've never suggested or implied otherwise.

But, if you like Distribute so much, why not just add it directly to 
the stdlib?  ;-)


AFAIK, the only reason they've had multiple releases of it is to 
address the issues with its hijacking of setuptools; in a stdlib 
version all that stuff could be dropped.  Otherwise, it'd already be "mature".


There are many wins to be had from such a move, not the least of 
which is that it allows something to go into the stdlib that isn't 
(branding-wise) associated with me or setuptools, and lets it become 
owned/supported by an even wider community.


Less political bickering, and the some of the technical results I 
hoped for all along are achieved.  Yay, open source.


___
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] eggs now mandatory for pypi?

[P.J. Eby]

At 10:17 PM 10/6/2009 +0200, M.-A. Lemburg wrote:

P.J. Eby wrote:
> At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
>> It goes a bit in the direction of what we had in mind with writing
>> for our clients: a tool that looks at the Python installation and
>> automatically finds/downloads/installs the right package from
>> our website. Only that we wanted to put up a single index file
>> for that tool to use, not one per package.
>
> That'd get a bit big for PyPI, though, with thousands of listed
> packages.  It's already pretty slow whenever somebody miscapitalizes or
> mis-punctuates a package name and easy_install has to read the "file"
> that just lists all the package names.  That, of course, is more a
> function of the fact that PyPI's "simple" API doesn't support
> canonicalization, although I believe certain other PyPI-mirroring and
> package indexing apps do.

The above was only meant for our eGenix packages, not PyPI.

For PyPI the natural answer to this is to use the already existing
PyPI XML-RPC interface:

http://wiki.python.org/moin/PyPiXmlRpc

This would only have to grow a few more fields for the release
downloads in order to be able to match the user's Python configuration
to the available release downloads.


Yes, but it's not easily duplicated by somebody who's just got a 
plain ol' web page, nor is it amenable to static page mirroring.  A 
GET-only REST API, on the other hand, is compatible with both. 


___
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] transitioning from % to {} formatting

[Greg Ewing]

Has anyone considered the idea of having the string % operator
behave intelligently according to the contents of the format
string?

If it contains one or more valid %-formats, use old-style
formatting; if it contains one or more valid {}-formats,
use new-style formatting.

Ambiguous cases could arise, of course, but hopefully they
will be fairly rare, and raising an exception would point
out the problem and allow it to be fixed.

--
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] PEP 3144 review.

[Greg Ewing]

Peter Moody wrote:

it's useful to take an
address like 192.168.1.100/24 and derive a bunch of information from
it (like the network address, broadcast address, containing supernets,
etc), but still remember that the original address was 192.168.1.100.
having a separate class or two for this is overly burdensome in my
mind.


Seems to me what you want isn't so much an IPNetwork that
can optionally have an address, as an IPAddress that can
optionally have a mask, and methods for deriving those
other things from it.

--
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] transitioning from % to {} formatting

[Greg Ewing]

Martin v. Löwis wrote:


So if a decision was made to eventually remove % formatting, it would
be reasonable to start migrating code to PEP 3101. However, no such
decision has been made (and hopefully won't be throughout 3.x)


If it's not done during 3.x, then by the time 4.x comes
around, there will still be heaps of code around that
uses %-formatting, so it won't be possible to remove
it in 4.x either.

--
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] Announcing PEP 3136

[Greg Ewing]

Yuvgoog Greenle wrote:


When is the else after a loop executed?

> 1. When the loop isn't entered at all.

2. When the loop terminates through exhaustion of the list (does this
include when the list was empty?)
3. When the loop didn't exit because of a break statement.


1 and 3 are just special cases of 2, when you include
the empty-list case. So you're making it more complicated
in your mind than it really is.


Any chances of cleaning this one up for python 4?


I doubt that many other people will see anything
here that needs cleaning up.

--
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] PEP 3144 review.

[Greg Ewing]

Paul Moore wrote:

linus and snoopy are hosts not networks, so
making them IPv4Network classes seems wrong. I'd instinctively make
them IPv4Address objects (which, I believe, would work).


However, by allowing IPNetwork objects to also contain
a host address, we seem to be officially sanctioning
such abuse, or at least turning a blind eye to it.

It's possible that the user is thinking of linus and
snoopy as being *both* networks and host addresses,
in which case this kind of mistake will be easy to
make. Not to mention the potential confusion in the
mind of someone trying to read or maintain the code.

My feeling is that we shouldn't accept this kind of
compromise as being "good enough". Once a module is
in the stdlib, we're going to be stuck with it for
quite a while, so I think it's worth taking some
time to make sure that what we adopt is based on a
conceptually sound design.

Peter is of course within his rights not to change
his module in this way. But this just means that
ipaddr is not the right module to adopt, and we
should design another one and give it a different
name.

--
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] transitioning from % to {} formatting

[Guido van Rossum]

On Fri, Oct 2, 2009 at 6:29 PM, Greg Ewing  wrote:
> Has anyone considered the idea of having the string % operator
> behave intelligently according to the contents of the format
> string?
>
> If it contains one or more valid %-formats, use old-style
> formatting; if it contains one or more valid {}-formats,
> use new-style formatting.
>
> Ambiguous cases could arise, of course, but hopefully they
> will be fairly rare, and raising an exception would point
> out the problem and allow it to be fixed.

Hm... The % operator already does too much guessing: if the string
contains exactly one %-format, the argument may be either a size-1
tuple or a non-tuple, otherwise it has to be a size-N tuple, except if
the %-formats use the %(name)X form, then the argument must always be
a dict. It doesn't sound to me as if adding more guesswork is going to
improve its reliability.

-- 
--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] eggs now mandatory for pypi?

[David Lyon]

On Tue, 06 Oct 2009 13:52:34 -0400, "P.J. Eby" 
wrote:
> Btw, every couple years or so I've sent out a call on the 
> distutils-SIG to try to get consensus on a format for the platform 
> tag information used by setuptools.  (The first time was before 
> easy_install even existed.)  Unfortunately, it's rare that anybody 
> contributes more than criticism of the existing scheme.  The last 
> updates to the scheme were by Mac folks, who at least had a clear 
> vision of what was needed.  There's been some win32/win64 discussion 
> in the past, but no proposals or patches of comparable 
> specificity.  

Consider the fact that Mac users won't answer or discuss posts by some 
windows users..

Why do this ? Why stir up platform bias?

Fact is Phil, windows users get *turned-away* at the door in
distutils... or ignored. Issues can hang around for years.

And your post is now asking "why no windows users?"

Go figure.. nobody answers them or takes issues seriously.

Distutils for windows is very, very dead.. grave-ware in-fact.

It should be quite obvious that windows users are forked off.. 

Why would windows people make proposals when they know it 
won't go anywhere...

David




___
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