On Sun, Oct 5, 2008 at 6:59 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Setuptools declares dependencies, but does not add a Python version
>> requirement,
>> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/)
>> with a new metadata called 'Requires Python'
>>
>>
Eric Smith wrote:
> I think it's a little too cute, and 'pass' is preferable.
Agreed - it was just a little surreal to put the "..." in as my usual
pseudo-code "stuff happens here" marker, only to realise what I had
written was still executable Py3k code.
Cheers,
Nick.
--
Nick Coghlan | [EM
Matthew Hawkins wrote:
> If there's another way of doing this I'd like to hear it.
The pass statement is still the right way to denote an empty block (the
compiler is already able to detect that and optimise the code
appropriately).
My tangential comment was based on the fact that this keyword co
Nick Coghlan wrote:
it was
just odd to notice that the Py3k interpreter would quite happily execute
the example code in my postscript when I had really only intended to
write it as pseudo-code with sections missing.
Well, they do say that Python is executable
pseudocode. :-)
--
Greg
__
Greg Ewing wrote:
> Nick Coghlan wrote:
>> it was
>> just odd to notice that the Py3k interpreter would quite happily execute
>> the example code in my postscript when I had really only intended to
>> write it as pseudo-code with sections missing.
>
> Well, they do say that Python is executable
>
> A problem with overloading the Categories field with Python version
> compatability information is that it makes for a poor user-interface. On
> the release page for a package, I'd rather see a Python Version field
> than having to look through a potentially large list of Categories.
That's an i
Martin v. Löwis wrote:
>> A problem with overloading the Categories field with Python version
>> compatability information is that it makes for a poor user-interface. On
>> the release page for a package, I'd rather see a Python Version field
>> than having to look through a potentially large list
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:
Setuptools declares dependencies, but does not add a Python version
requirement,
like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/
)
with a new metadata called 'Requires Python'
Even if the problem is fixed in shor
2008/10/5 Kevin Teague <[EMAIL PROTECTED]>:
> on Python 3 after running it through 2to3. The source code is different so
> that to me suggests different version numbers - but the API will be the
> same, so maybe the same version number should be used? That is should there
> be?
>
> foobar-1.0-py2.
[Steve Holden"]
Of course there is also the option of treating Python 3 as a different
language, and having a Py3Pi website as well. This might not be as
wasteful as it at first seems.
It would be nice if we had a way of marking Py2.6 recipes that still
work when run through 2-to-3 and then au
> Of course there is also the option of treating Python 3 as a different
> language, and having a Py3Pi website as well. This might not be as
> wasteful as it at first seems.
Although it would be possible, I think it's not appropriate.
It would be fairly easy to implement, though: just create
pyp
>> foobar-1.0-py2.6.tar.gz
>> foobar-1.0-py3.0.tar.gz
>
> More likely, in this way:
>
> foobar-1.0-py2.tar.gz
> foobar-1.0-py3.tar.gz
How do you implement this in distutils? People probably won't rename
the files from how sdist names them. So it's more likely that they
come up with things like
I have a version of PyCXX ported to python 3.0 rc1 and its passing
its tests.
I'm porting pysvn to python 3.0 rc1 and hit an odd problem.
Given this dict:
wc_status_kind_map = {
pysvn.wc_status_kind.added: 'A',
pysvn.wc_status_kind.replaced: 'R',
> Why does "key in wc_status_kind_wc" work when I use an object returned
> by keys() by not when I use pysvn.wc_status_kind.unversioned?
This is too little detail to come up with an explanation. Do your
objects support __eq__.
Regards,
Martin
___
Python
Barry Scott wrote:
for key in [pysvn.wc_status_kind.added,
pysvn.wc_status_kind.replaced,
pysvn.wc_status_kind.unversioned]:
print( '2 key', key, key in wc_status_kind_map, cmp( key,
pysvn.wc_status_kind.unversioned ), hash( key ) )
try:
print( '2 lookup
This does make it look rather as though bytes == str was a decision
whose consequences weren't fully appreciated before implementation.
Was this horror anticipated?
regards
Steve
Original Message
Subject: In Python 2.6, bytes is str
Date: Sun, 05 Oct 2008 22:30:17 -0700
From:
On Sun, Oct 5, 2008 at 11:43 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> This does make it look rather as though bytes == str was a decision
> whose consequences weren't fully appreciated before implementation.
>
Well, you could say that about almost any change.
> Was this horror anticipated?
17 matches
Mail list logo
