Michael Foord writes:
> How is ~/python not memorable or consistent? (And cross-platform
> memorability and consistency is valuable too.)
But what does "~" mean on Windows? Inside of Python you can have a
consistent definition, but that doesn't help people whose installer
gets mixed signals so
Michael Foord writes:
> > I think the point is that *because* people don't want to change
> > their ideas, it would be good to have a mingw-based alternative.
> > Otherwise everyone is forced to convert to the Windows religion.
> You mean people using Windows are forced to use Windows?
By fa
On Fri, Aug 13, 2010 at 7:29 AM, Antoine Pitrou wrote:
> On Thu, 12 Aug 2010 18:14:44 -0400
> Glyph Lefkowitz wrote:
>>
>> On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
>>
>> > I don't care how many stats we're doing
>>
>> You might not, but I certainly do. And I can guarantee you that the
>> a
On Fri, Aug 13, 2010 at 03:15:28AM +0200, Éric Araujo wrote:
> > A good alternative would be to make the config file overridable. That way
> > you can have sysconfig.cfg next to sysconfig.py or in a known config
> > directory relative to the python stdlib install but also let the
> > distributions
Antoine Pitrou wrote:
> On Thu, 12 Aug 2010 18:14:44 -0400
> Glyph Lefkowitz wrote:
> >
> > On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
> >
> > > I don't care how many stats we're doing
> >
> > You might not, but I certainly do. And I can guarantee you that the
> > authors of command-line t
On 12 August 2010 20:37, Michael Foord wrote:
> On 13/08/2010 00:44, Greg Ewing wrote:
>>
>> Cesare Di Mauro wrote:
>>
>>> You must suggest at least an equivalent "free" alternative to make the
>>> switch convenient.
>>>
>>> Otherwise we are talking about philosophy or religion, and nobody will
>>
> A good alternative would be to make the config file overridable. That way
> you can have sysconfig.cfg next to sysconfig.py or in a known config
> directory relative to the python stdlib install but also let the
> distributions and individual sites override the defaults by making changes
> to /e
On Fri, Aug 13, 2010 at 07:48:22AM +1000, Nick Coghlan wrote:
> 2010/8/12 Éric Araujo :
> >> Choosing an arbitrary location we think is good on every system is fine
> >> and non risky I think, as long as Python let the various distribution
> >> change those paths though configuration.
> >
> > Don’t
On Thu, 12 Aug 2010 08:18:27 pm Steve Holden wrote:
> One might make a case that all configuration data should be stored in
> a single SQLite database (with a suitable API to hide the relational
> nature of the store).
-1
Please don't even *consider* such a thing. Haven't we learned from
Firefox
On 13/08/2010 00:44, Greg Ewing wrote:
Cesare Di Mauro wrote:
You must suggest at least an equivalent "free" alternative to make
the switch convenient.
Otherwise we are talking about philosophy or religion, and nobody
will change his ideas.
I think the point is that *because* people don't
Cesare Di Mauro wrote:
You must suggest at least an equivalent "free" alternative to make the
switch convenient.
Otherwise we are talking about philosophy or religion, and nobody will
change his ideas.
I think the point is that *because* people don't want to change
their ideas, it would be
> ... Highlights are:
>
> * numerous improvements to the unittest module
> * PEP 3147, support for .pyc repository directories
> * an overhauled GIL implementation that reduces contention
> * many consistency and behavior fixes for numeric operations
> * countless fixes regarding string/unicode is
On Thu, 12 Aug 2010 18:14:44 -0400
Glyph Lefkowitz wrote:
>
> On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
>
> > I don't care how many stats we're doing
>
> You might not, but I certainly do. And I can guarantee you that the
> authors of command-line tools that have to start up in under ten
On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
> I don't care how many stats we're doing
You might not, but I certainly do. And I can guarantee you that the authors of
command-line tools that have to start up in under ten seconds, for example
'bzr', care too.
> My argument goes that one of the biggest differences between the
> GNU/Linux and the Windows way of computing is the barrier between user
> and programmer. In the Windows way, you are either a user or a
> programmer.
Such arguments are off-topic for python-dev; please use one of the
Linux advoc
2010/8/12 Éric Araujo :
>> Choosing an arbitrary location we think is good on every system is fine
>> and non risky I think, as long as Python let the various distribution
>> change those paths though configuration.
>
> Don’t you have a bootstrapping problem? How do you know where to look at
> the
On 12/08/2010 12:56, Antoine Pitrou wrote:
Hello,
I would like to see “unit test needed” removed from the workflow menu in
the bug tracker. The reason is that we don't do test-driven development
(or, at least, most of us don't) and this stage entry is therefore
useless and confusing. Saying to s
On 12/08/2010 08:26, Tarek Ziadé wrote:
[snip...]
Choosing an arbitrary location we think is good on every system is fine
and non risky I think, as long as Python let the various distribution
change those paths though configuration.
In fact, that's one of the future goal of the sysconfig module
On Thu, 12 Aug 2010 11:02:29 -0400
Alexander Belopolsky wrote:
>
> I remember there was an idea somewhere to replace "patch" tag with a
> check-list with boxes for code, tests, and docs. I think that would
> be better than "unit test needed" stage.
To me the simpler the better. If there's a pat
On Thu, Aug 12, 2010 at 1:31 PM, Fred Drake wrote:
> On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky
> wrote:
>> I remember there was an idea somewhere to replace "patch" tag with a
>> check-list with boxes for code, tests, and docs. I think that would
>> be better than "unit test needed"
On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky
wrote:
> I remember there was an idea somewhere to replace "patch" tag with a
> check-list with boxes for code, tests, and docs. I think that would
> be better than "unit test needed" stage.
Are you suggesting check boxes for what's needed,
2010/8/12
>
> On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote:
> > On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden
> wrote:
> > >
> > > "David Cournapeau":
> > >> Autotools only help for posix-like platforms. They are certainly a big
> > >> hindrance on windows platform in gener
On Thu, Aug 12, 2010 at 9:18 AM, Mark Dickinson wrote:
> On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou wrote:
..
>> I would like to see “unit test needed” removed from the workflow menu in
>> the bug tracker.
..
> Is that stage supposed to (at least partly) capture the idea
> 'reproducible tes
On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote:
> On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden wrote:
> >
> > "David Cournapeau":
> >> Autotools only help for posix-like platforms. They are certainly a big
> >> hindrance on windows platform in general,
> >
> > That is why ming
On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou wrote:
>
> Hello,
>
> I would like to see “unit test needed” removed from the workflow menu in
> the bug tracker. The reason is that we don't do test-driven development
> (or, at least, most of us don't) and this stage entry is therefore
> useless a
On Thu, Aug 12, 2010 at 6:18 AM, Steve Holden wrote:
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location? We ruin the risk
> of Python becoming distributed so finely it becomes impossible to change
> things, what with per-user l
> Ultimately, I don't feel very strongly about this subject. I'm more
> concerned that the chosen location (file or registry or whatever) be
> documented -- and documented from a Windows perspective as well, so
> you don't have to guess what "HOME" means in this context.
Rest assured that I don’t
On 12 August 2010 12:59, Tim Golden wrote:
> re: using the Registry: To be honest, I was answering the literal
> question posed by Eric: where to put config files? Not the wider
> question: how should config data be stored? Where the answer to
> the latter question might be: the Registry -- much a
Le 12/08/2010 12:18, Steve Holden a écrit :
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location?
As pointed out by Antoine, Georg, Michael and I, the PEP 370 directory
for user site-packages is not the right place to put config
>> If the files are shared among all users then /usr/local/
>> seems more reasonable.
Oh, right, I forgot to think about system-wide config files. They have
to be supported by another function in site.
A lot of programs have similar-looking code to get a list of filenames
and then process it with
On 12/08/2010 12:17, Michael Foord wrote:
How is ~/python not memorable or consistent? (And cross-platform
memorability and consistency is valuable too.)
I was thinking outside Python rather than inside it (where ~ has no
meaning on Windows) but you make a good point here. If we were just
disc
Hello,
I would like to see “unit test needed” removed from the workflow menu in
the bug tracker. The reason is that we don't do test-driven development
(or, at least, most of us don't) and this stage entry is therefore
useless and confusing. Saying to someone that an unit test is needed
happens d
On 12/08/2010 11:54, Tim Golden wrote:
On 12/08/2010 11:40, Michael Foord wrote:
User editable configuration files are very different from libraries. The
per user site-packages folder *should* be hidden somewhere out of the
way where you can get at them if you want them but won't stumble across
On 12/08/2010 11:40, Michael Foord wrote:
User editable configuration files are very different from libraries. The
per user site-packages folder *should* be hidden somewhere out of the
way where you can get at them if you want them but won't stumble across
them all the time. e.g. AppData on Windo
On 12/08/2010 11:18, Steve Holden wrote:
On 8/12/2010 5:50 AM, Tim Golden wrote:
On 11/08/2010 16:22, Éric Araujo wrote:
It would be nice to define one standard location for config files used
by stdlib modules, and maybe also by third-party programs related
closely to Python developme
On 12/08/2010 10:50, Tim Golden wrote:
Unfortunately, the canonical place is not always the place most
used. Especially since the convention under *nix is to place dotfile
or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
various locations are considered $HOME, including (but n
On 12/08/2010 11:18, Steve Holden wrote:
On 8/12/2010 5:50 AM, Tim Golden wrote:
[... snip explanation of standard & non-standard locations ...]
Didn't we have this discussion when per-user libraries came up?
Shouldn't we be using a subdirectory of that location?
Yes we should. My explanati
On 8/12/2010 5:50 AM, Tim Golden wrote:
> On 11/08/2010 16:22, Éric Araujo wrote:
>> It would be nice to define one standard location for config files used
>> by stdlib modules, and maybe also by third-party programs related
>> closely to Python development (testing tools, static code checkers and
On 11/08/2010 16:22, Éric Araujo wrote:
It would be nice to define one standard location for config files used
by stdlib modules, and maybe also by third-party programs related
closely to Python development (testing tools, static code checkers and
the like), in a way that doesn’t clutter the user
On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden wrote:
>
> "David Cournapeau":
>> Autotools only help for posix-like platforms. They are certainly a big
>> hindrance on windows platform in general,
>
> That is why mingw has MSYS.
I know of MSYS, but it is not very pleasant to use, if only because
On Thu, Aug 12, 2010 at 7:00 AM, Russell E. Owen wrote:
...
>
> If the files are shared among all users then /usr/local/
> seems more reasonable.
>
> I also think whatever you choose for linux is also the best choice for
> Mac OS X (my preferred platform). While there are other possible
> director
41 matches
Mail list logo
