Petri Lehtinen wrote:
> Georg Brandl wrote:
> > On 10/23/11 20:54, petri.lehtinen wrote:
> > > http://hg.python.org/cpython/rev/5c4781a237ef
> > > changeset: 73073:5c4781a237ef
> > > branch: 2.7
> > > parent: 73071:11da12600f5b
> > > user:Petri Lehtinen
> > > date:Sun O
Georg Brandl wrote:
> On 10/23/11 20:54, petri.lehtinen wrote:
> > http://hg.python.org/cpython/rev/5c4781a237ef
> > changeset: 73073:5c4781a237ef
> > branch: 2.7
> > parent: 73071:11da12600f5b
> > user:Petri Lehtinen
> > date:Sun Oct 23 21:52:10 2011 +0300
> > summary:
On Sun, Oct 23, 2011 at 20:58, Mark Hammond wrote:
> On 24/10/2011 12:56 PM, Michael Urman wrote:
>>
>> On Sun, Oct 23, 2011 at 17:15, Mark Hammond
>> wrote:
>>>
>>> How about abusing the existing flags for this purpose - eg:
>>>
>>> % py -3?
>>> % py -2.7?
>>
>> I would have expected that to lau
On 24/10/2011 12:56 PM, Michael Urman wrote:
On Sun, Oct 23, 2011 at 17:15, Mark Hammond wrote:
How about abusing the existing flags for this purpose - eg:
% py -3?
% py -2.7?
I would have expected that to launch an interactive python shell of
the appropriate version. Does it do something el
On Sun, Oct 23, 2011 at 17:15, Mark Hammond wrote:
> How about abusing the existing flags for this purpose - eg:
>
> % py -3?
> % py -2.7?
I would have expected that to launch an interactive python shell of
the appropriate version. Does it do something else today?
Michael
___
On Mon, Oct 24, 2011 at 11:15 AM, Mark Hammond
wrote:
>> So I don't actually see any particularly *new* design decisions to be
>> made in relation to a "--which" option - it's just a workaround for
>> the lack of a native 'which' equivalent on Windows,
>
> Actually I don't think that is true - eve
On 24/10/2011 11:46 AM, Nick Coghlan wrote:
On Mon, Oct 24, 2011 at 10:00 AM, Mark Hammond wrote:
* The "magic" symbol is somewhat self-documenting - it implies a question.
Using --which adds another special case that people would need to
understand isn't passed to Python. IOW, I like that
On Mon, Oct 24, 2011 at 10:00 AM, Mark Hammond wrote:
> * The "magic" symbol is somewhat self-documenting - it implies a question.
> Using --which adds another special case that people would need to
> understand isn't passed to Python. IOW, I like that there is only 1 special
> option and that
On 24/10/2011 10:36 AM, Nick Coghlan wrote:
On Mon, Oct 24, 2011 at 8:15 AM, Mark Hammond wrote:
How about abusing the existing flags for this purpose - eg:
% py -3?
% py -2.7?
What does using the magic symbol offer over an explicit separate flag?
* The "magic" symbol is somewhat self-docu
On Mon, Oct 24, 2011 at 8:15 AM, Mark Hammond wrote:
> How about abusing the existing flags for this purpose - eg:
>
> % py -3?
> % py -2.7?
What does using the magic symbol offer over an explicit separate flag?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 23/10/2011 12:27 AM, Paul Moore wrote:
(Sorry, should have gone to the list...)
On 22 October 2011 13:15, Vinay Sajip wrote:
Nick Coghlan gmail.com> writes:
As a simpler alternative, I suggest the launcher just gain a "--which"
long option that displays the full path to the interpreter
>> So why remove them?
>
> Not worrying whether we should maintain these files or not would be a
> reason. Not worrying whether we should document them (or provide a
> better way to access these facilities) is another.
Don't worry whether, I tell you :-) Yes, we maintain them, and no,
we make no
> -1. If they were broken, and somebody used them, a bug would be
> reported. That no bug is being reported means that they either
> work fine, or nobody uses them.
>
> In the former case, removing them will break somebody's code.
> In the latter case, nothing is gained by either keeping or remov
> I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ...
> (after we put memcmp in unicode_compare)
-1. We shouldn't do anything about this. Python has the tradition of not
working around platform bugs, except if the work-arounds are necessary
to make something work at all - i.e
> I don't understand why we kept modules of the plat-* directories (e.g.
> Lib/plat-linux/CDROM.py).
Because they are useful. There is no reasonable other way at getting at
the information in the modules for a Python program that may need them.
> These modules are not regenerated when Python is
> Given the issues you are mentioning, and given they were never
> reported in years before, it seems unlikely anybody is using these
> files.
>
> +1 to remove them, as they don't seem documented either.
-1. If they were broken, and somebody used them, a bug would be
reported. That no bug is bein
On 10/23/11 20:54, petri.lehtinen wrote:
> http://hg.python.org/cpython/rev/5c4781a237ef
> changeset: 73073:5c4781a237ef
> branch: 2.7
> parent: 73071:11da12600f5b
> user:Petri Lehtinen
> date:Sun Oct 23 21:52:10 2011 +0300
> summary:
> Whoops, PyException_GetTracebac
I am out of the office until 10/27/2011.
I am out of the office attending the IBM IOD conference. I will be back in
the office on Friday, 10/28. My email responses will be delayed during
that period.
Note: This is an automated response to your message "Python-Dev Digest,
Vol 99, Issue 45" s
18 matches
Mail list logo
