On 9/18/2010 10:03 PM, Nick Coghlan wrote:
> On Sun, Sep 19, 2010 at 4:18 AM, John Nagle wrote:
>> On 9/18/2010 2:29 AM, python-dev-requ...@python.org wrote:
>>>
>>> Polymorphic best practices [was: (Not) delaying the 3.2 release]
>>
>> If you're hung up on this, try writing the user-level docum
On Sun, Sep 19, 2010 at 4:18 AM, John Nagle wrote:
> On 9/18/2010 2:29 AM, python-dev-requ...@python.org wrote:
>>
>> Polymorphic best practices [was: (Not) delaying the 3.2 release]
>
> If you're hung up on this, try writing the user-level documentation
> first. Your target audience is a worki
On 2010-09-18, at 2:29 AM, Thomas Lotze wrote:
> I'd like to expand [tl.eggdeps]
> to analyse dependencies between any packages on PyPI but I can't
> as long as dependency information is not available without actually
> installing things. [...]
On 2010-09-18, at 2:29 AM, Thomas Lotze wrote:
>>
Victor Stinner wrote:
Eg. one of the most important function of pysandbox is
proxy() (a function to create a read only view of a object outside the
sandbox, especially on an import), if you replace isinstance() by a function
which always return True: you can get unmodified objects
I don't f
Robert Collins wrote:
__builtins__ is in everyone's global namespace, so if it can be
mutated, different python programs running in the same sandbox can
affect each other.
So give each program its own copy of __builtins__.
--
Greg
___
Python-Dev mai
On Sat, Sep 18, 2010 at 2:39 PM, Chris Withers wrote:
> I'm curious as to why, with a file called "Foo.txt" on a case descriminating
> but case insensitive filesystem, os.path.normcase('FoO.txt') will return
> "foo.txt" rather than "Foo.txt"?
>
> Yes, I know the behaviour is documented, but I'm wo
Hi All,
I'm curious as to why, with a file called "Foo.txt" on a case
descriminating but case insensitive filesystem,
os.path.normcase('FoO.txt') will return "foo.txt" rather than "Foo.txt"?
Yes, I know the behaviour is documented, but I'm wondering if anyone can
remember the rationale for t
Am 18.09.2010 15:27, schrieb Steve Holden:
> On 9/18/2010 9:21 AM, "Martin v. Löwis" wrote:
>> IT WILL BE NOT IN PREFERENCE TO DISTUTILS2.
>
> No need to shout.
I really felt that this otherwise wouldn't be heard - I tried
to say it a number of times before, and it was ignored.
Regards,
Martin
_
"Martin v. Löwis" wrote:
>> So you are fine with publishing "slightly incorrect" metadata at PyPI
>> ? I am not.
>
> I really have no intuition for in how many cases the data will be
> incorrect. However, if users find that the data is incorrect for
> specific package, they ought to complain to th
2010/9/18 "Martin v. Löwis" :
> Any other opinions?
-1 from me as well; I see no reason to encourage use of bad metadata,
given mechanisms to get correct metadata exist (running "setup.py
egg_info", as others have pointed out). I understand there are
perceived uses for such data, but it's just as
On 18/09/2010 18:27, Nick Coghlan wrote:
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
wrote:
On 18/09/2010 12:25, "Martin v. Löwis" wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provid
On 9/18/2010 2:29 AM, python-dev-requ...@python.org wrote:
Polymorphic best practices [was: (Not) delaying the 3.2 release]
If you're hung up on this, try writing the user-level documentation
first. Your target audience is a working-level Web programmer, not
someone who knows six programmin
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
wrote:
> On 18/09/2010 12:25, "Martin v. Löwis" wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't
At 06:06 PM 9/18/2010 +0200, Martin v. Löwis wrote:
Am 18.09.10 17:49, schrieb P.J. Eby:
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect, people
Stephen J. Turnbull wrote:
> In the meantime, it's better to let people using a competing "standard"
> (even if it's neither very good nor a "real" standard) do their thing
> until they see the light.
It's not even about the people who consume egg-info data seeing the light,
it's about PEP-345 da
Am 18.09.10 17:49, schrieb P.J. Eby:
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect, people would notice if they try to use the packages in
ques
So you are fine with publishing "slightly incorrect" metadata at PyPI
? I am not.
I really have no intuition for in how many cases the data will be
incorrect. However, if users find that the data is incorrect for
specific package, they ought to complain to the maintainer.
I don't understand
Tarek Ziadé writes:
> "Good enough metadata" sounds completely wrong to me.
I hate to break it to you, but experience shows that the XEmacs
package system, whose dependency tracking is in theory a pile of
braindamaged rubbish, an abomination in the sight of She Who Created
The World With 4-Space
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect, people would notice if they try to use the packages in
question.
By the way, just providing t
2010/9/18 "Martin v. Löwis" :
>> So, I don't understand what is the benefit here, since a serious
>> installer will re-run egg_info every time.
>
> I think the main applications that people are after are not builds.
> They want the dependency information without downloading the packages,
> and depe
So, I don't understand what is the benefit here, since a serious
installer will re-run egg_info every time.
I think the main applications that people are after are not builds.
They want the dependency information without downloading the packages,
and dependency information for packages they have
So if the use case is to provide dependency information exposing
egg_info is not the right way to do it - and tools that use it will be
using potentially (and frequently) inaccurate information. I stand by
the point that once we start providing this information tools will start
using it, and they
On Sat, Sep 18, 2010 at 4:01 PM, Michael Foord
wrote:
> Ok, I'm sorry - PEP 345 information is available via the PyPI API. (So
> exposing egg_info would not be promoting it *over* distutils2 but it would
> still be promoting and blessing it).
>
> Tarek's main point still stands though. The depend
Ok, I'm sorry - PEP 345 information is available via the PyPI API. (So
exposing egg_info would not be promoting it *over* distutils2 but it
would still be promoting and blessing it).
Tarek's main point still stands though. The dependency information in
the egg_info is tied to the platform and
On 9/18/2010 9:21 AM, "Martin v. Löwis" wrote:
> IT WILL BE NOT IN PREFERENCE TO DISTUTILS2.
No need to shout.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video! http://python.mirocommunity.o
No. See above comment. If exposing this information has no value then
don't do it. If it does have value, then we are blessing it - and
therefore blessing it *over* other formats.
No: not *over*. Only over formats that don't get exposed. However,
the PEP 345 data are *already* exposed, via HTML,
On 18/09/2010 12:25, "Martin v. Löwis" wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't will not. The infrastructure is
entirely
agnostic on whether the data is av
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't will not. The infrastructure is entirely
agnostic on whether the data is available or not. In particular, it will
not try to
On Sat, Sep 18, 2010 at 7:50 PM, Michael Foord
wrote:
> On 18/09/2010 11:48, David Cournapeau wrote:
>>
>> On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
>> wrote:
>>>
>>> On 18/09/2010 11:03, "Martin v. Löwis" wrote:
That's really sad. So people will have to wait a few years to
On 18/09/2010 11:48, David Cournapeau wrote:
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
wrote:
On 18/09/2010 11:03, "Martin v. Löwis" wrote:
That's really sad. So people will have to wait a few years to efficiently
implement tools that they could implement today.
Why a few years?
Tha
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
wrote:
> On 18/09/2010 11:03, "Martin v. Löwis" wrote:
>> That's really sad. So people will have to wait a few years to efficiently
>> implement tools that they could implement today.
>
> Why a few years?
That's the time it will take for all packag
On 18/09/2010 11:03, "Martin v. Löwis" wrote:
With the distutils2 work very close to landing in the standard library,
providing infrastructure that will cause tools to *depend* on the old
formats is a very bad idea.
I think you are misunderstanding. The infrastructure will *not* depend
on the
Le samedi 18 septembre 2010 07:40:44, hirokazu.yamamoto a écrit :
> Author: hirokazu.yamamoto
> Date: Sat Sep 18 07:40:44 2010
> New Revision: 84877
>
> Log:
> Added missing import.
>
> Modified: python/branches/release27-maint/Lib/posixpath.py
> ==
Le samedi 18 septembre 2010 10:39:58, Robert Collins a écrit :
> __builtins__ is in everyone's global namespace, so if it can be
> mutated, different python programs running in the same sandbox can
> affect each other.
>
> Ditto sys.modules and os environ, but I guess that those are already
> addr
With the distutils2 work very close to landing in the standard library,
providing infrastructure that will cause tools to *depend* on the old
formats is a very bad idea.
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that i
Le samedi 18 septembre 2010 10:24:49, Greg Ewing a écrit :
> Victor Stinner wrote:
> > I'm still developing irregulary my sandbox project since last june.
> >
> > Today, the biggest problem is the creation of a read only view of the
> > __builtins__ dictionary.
>
> Why do you think you need to do
On 18/09/2010 08:52, "Martin v. Löwis" wrote:
I am in full agreement with Tarek here. At ActiveState, we maintain
our own index that differs from PyPI in two ways (among others):
I think you are saying something very different from what Tarek
says. IIUC, you are saying that egg-info is ill-def
Hi there,
I'm going to add my own 2 cents to the discussion as I'm involved in the
matter here at the DZUG conference.
Tarek Ziadé wrote:
> Now you want to publish another metadata format at PyPI ? If PyPI takes
> that direction and adopts, promotes and publishes a standard that is not
> the one
On Sat, Sep 18, 2010 at 8:24 PM, Greg Ewing wrote:
> Victor Stinner wrote:
>
>> I'm still developing irregulary my sandbox project since last june.
>
>> Today, the biggest problem is the creation of a read only view of the
>> __builtins__ dictionary.
>
> Why do you think you need to do this? What
Victor Stinner wrote:
I'm still developing irregulary my sandbox project since last june.
Today, the biggest problem is the creation of a read only view of the
__builtins__ dictionary.
Why do you think you need to do this? What form of attack
would a writable __builtins__ expose you to that
I am in full agreement with Tarek here. At ActiveState, we maintain
our own index that differs from PyPI in two ways (among others):
I think you are saying something very different from what Tarek
says. IIUC, you are saying that egg-info is ill-defined and may
cause subtle problems. So you are s
41 matches
Mail list logo
