Re: [Python-3000] [Python-Dev] Py3k: error during 'make install' in py3k-struni ?
Guido van Rossum wrote: > What's broken about pickle on the struni branch? It passes all its tests. > My brain ... :( I had some old code laying around. After svn revert + svn up all pickle tests are passing. *blush* Christian ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] pep 3124 plans
On Mon, 23 Jul 2007, Talin wrote: > Phillip J. Eby wrote: > > > I just don't see that the things Greg is describing aren't equally > > applicable to traditional methods. > > I wasn't going to get into this, but - since you asked :) > > The short form of the argument is that being able to overload any > function as a generic function retroactively changes the implicit > contract of what that function is. I don't think this is really true in programs written with good taste - ie, it's no more true than in the OO case. In the OO case, one might consider the class of an object to be closely associated with a contract describing its intended semantics (its type). If a function takes a parameter and is written expecting that it is passed an argument of type B (for come class B), then by subclassing B into a derived class, D, you _ought_ to be able to pass an instance of D to the same function which should be able to use it, regardless. That's what subclassing _means_: if D is a subclass of B, then all instances of D should behave appropriately and according to the intended semantics of B when used as a B. Of course, it's perfectly possible to abuse subclassing to acquire implementation rather than the type/contract, but well-written* OO programs at least draw a clear distinction between those uses if they do it at all. So, when you look at an OO program that makes extensive use of subclassing, you typically have a notion of what method calls should do at a broad semantic level because that notion is part of the contract implicit in the type. Exactly the same is true with GFs. Yes, you can overload "add()" to mean "subtract" or "remove a random file" or "close all database connections" in certain cases. That's painfully flying in the face of the intended semantics of the function you're overloading; so, don't do that. Cheers, jan * Excuse the unavoidably emotive terminology like "well-written". I know there are other views - I'm just arguing this one. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Spreadsheet through network. Oh yeah. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] struni and the Apple four-character-codes
I've CC-ed Jack Jansen as he has maintained the Mac libraries for ages (from way before OS9 was shiny and new). On Wednesday, July 25, 2007, at 07:18AM, "Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote: >I'm looking through a couple of the OS X tests and have run into the >question of what to do with four-character codes. (For those of you >who are unfamiliar with these, Apple, around the dawn of time, decided >that C constants like 'TEXT' (yes, those are single quotes) would >compile to the uint32_t 0x54455854 (or maybe the other-endian version >of that) so they could use these as cheap-but-readable type AFAIK the are always converted as big-endian values. >identifiers.) In Python 2, these are represented as 'str' instances, >which PyMac_GetOSType() in Python/mactoolboxglue.c converts to the >native int format. For Python 3, right now they're str8's, but str8 is >theoretically supposed to go away. Because they're binary constants >displayed as ASCII, not unicode text, I initially thought that 'bytes' >was the appropriate type. Unfortunately, bytes is mutable, and I think >it makes sense to hash these constants (and some code in aepack.py >does). > >So, I'm stuck and wanted to ask the list for input. I see 5 options: > 1) Make these str instances so they're immutable and just rely on >convention and runtime errors to keep them in ascii. > 2) Make them bytes, and cast them to something else when you want to >make them keys in a dict. > 3) Keep them str8 and give up on getting rid of it. > 4) Make bytes immutable, add a 'buffer' type which acts like the >current bytes type, and make these codes instances of bytes. [probably >impossible this late in the game] > 5) Make a new hashable class for these codes which converts them to >and from ints and bytes and becomes the general argument type for the >apple platform interface. [Cleanest, but lots of work that I'm not >volunteering to do] A 6th option is a subclass of int. It's constructor would accept a string containing the 4CC and the repr/str method would return the string representation of the code. IMHO this is the cleanest representation of 4CCs in Python because those codes are basicy a "neat" way to enter integer literals in C. This would also solve a problem that PyObjC users sometimes run into: Several C/Objective-C APIs return a dictionary where one of the values is an integer and where one would commonly use 4CCs to write down literals. This currently causes unexpected failures but would do the right thing with this option. Ronald ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] New section for PEP 3124
Phillip J. Eby wrote: > For example, epydoc and pydoc contain functions that inspect the type > of their arguments in order to decide what to with them. While it's > arguable that in a GF world, the authors *should* have made those > functions overloadable, it isn't reasonable to expect everyone to > rewrite their code to make everything overloadable, nor to correctly > anticipate every function for which extension might be needed. That makes me wonder. Will it be possible to monkeypatch a function to make it overloadable? I don't know if people will really do that, but at least the irony would be worth it. -- Benji York http://benjiyork.com ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Py3k: error during 'make install' in py3k-struni ?
>>> Afther checking out the py3k-struni branch, 'make install' issued this:
>>>
>>> Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
>>> *** SyntaxError: ('expected string, bytes found',
>>> ('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
>>> None))
>>>
>>> If this is expected to fail, please forget this.
>
> It should not faild but we know that it is failing. The module isn't
> easy to fix either. I spent about an hour on tarfile.py without any
> luck. It's a beast and seems to be rather old style code from the Python
> 1.x days.
Don't despair, the white knight in shining armor might not be too far
away to safe you from the dragon :-)
Seriously, Lars Gustäbel (CC'ed) has always been quite helpful in
fixing whatever problem arise with the tarfile module.
Lars, do you have a chance to look at porting the
module to 3k/struni?
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Py3k: error during 'make install' in py3k-struni ?
On Wed, Jul 25, 2007 at 07:26:45PM +0200, "Martin v. Löwis" wrote:
> >>> Afther checking out the py3k-struni branch, 'make install' issued this:
> >>>
> >>> Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
> >>> *** SyntaxError: ('expected string, bytes found',
> >>> ('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
> >>> None))
> >>>
> >>> If this is expected to fail, please forget this.
> >
> > It should not faild but we know that it is failing. The module isn't
> > easy to fix either. I spent about an hour on tarfile.py without any
> > luck. It's a beast and seems to be rather old style code from the Python
> > 1.x days.
>
> Don't despair, the white knight in shining armor might not be too far
> away to safe you from the dragon :-)
Yea, I heard that call :-)
> Seriously, Lars Gustäbel (CC'ed) has always been quite helpful in
> fixing whatever problem arise with the tarfile module.
>
> Lars, do you have a chance to look at porting the
> module to 3k/struni?
I just took a quick look at it, but I could not reproduce the
above error message. However, it is obvious that tarfile.py is
completely unusable in py3k-struni and it is my job to fix it,
which seems to me far from trivial at the moment. I have to
catch up with py3k development as well, so I am not able to
estimate when the job will be done.
--
Lars Gustäbel
[EMAIL PROTECTED]
The world is a tragedy to those who feel, but a comedy
to those who think.
(Horace Walpole)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] struni and the Apple four-character-codes
Jeffrey Yasskin wrote: > Apple, around the dawn of time, decided > that C constants like 'TEXT' (yes, those are single quotes) would > compile to the uint32_t 0x54455854 They weren't C constants originally, they were Pascal constants, and it made sense at the time given the way the Pascal compiler they were using handled string literals. They also worked okay as multi-character char literals in the early C compilers used on the Mac. It's unfortunate that gcc gets persnickety about those. > I initially thought that 'bytes' > was the appropriate type. Unfortunately, bytes is mutable, and I think > it makes sense to hash these constants (and some code in aepack.py > does). Is this another indication that we should have an immutable version of the bytes type? -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] struni and the Apple four-character-codes
On 26 Jul, 2007, at 4:07, Greg Ewing wrote: I initially thought that 'bytes' was the appropriate type. Unfortunately, bytes is mutable, and I think it makes sense to hash these constants (and some code in aepack.py does). Is this another indication that we should have an immutable version of the bytes type? No. Four-character-constants are *not* strings or byte arrays, they are integer literals. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
