[Python-Dev] Re: Suggestion: a little language for type definitions
Barry: > The advantage to users of keeping the languages the same is that readers of > your code don’t have to learn two disparate syntaxes to make sense of what > they’re reading. One of Python’s enduring strengths has been its > readability. Agreed. But if the little language is (a) clearly flagged and (b) has a different domain I think this is much less of a problem. I don’t think f-strings are seen as a problem, far from it, because they’re clearly flagged. That’s why I suggested t-strings. And while from a Python parser point-of-view the grammar of current type expressions are the same as the grammar of other Python code I think that for human readers this is not the case: there’s a lot of square brackets but nothing is being indexed, to name one major readability issue... Stéfane: > Using the same syntax may have some benefits for language implementors (e.g. > less complex grammar to implement), but I don’t really see these benefits for > language users. > > As an example, and I don’t know if this has been discussed before, I think a > pretty neat syntax construct for optional argument would be (like, for > instance, in Kotlin): > > def f(x: int? = None): ... I introduced the t-strings specifically because I think it would be beneficial to have the little language a clearly flagged and have as little interaction with “normal” Python as possible. Your example here works fine for Optional, and looks pretty understandable if you know C# (or apparently Kotlin), but it doesn’t solve all the other problems with readability. And I think you’ll quickly run out of constructs once you try to fix more problems if you don’t want to clash with existing Python syntax… -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HLHH3VFNA32M2JHJIZ5OSWKHTCZLOJLH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On 8 Jan 2022, at 23:05, Skip Montanaro wrote: >> ... make sense of what they’re reading. > Some of us have that problem with type-embellished code now. I'm not sure a > little language would be such a bad idea. 樂 Fortunately, my relationship to > the working world allows me to simply ignore explicit typing. Yeah, that was my take too, until about a year ago. In the last year I’ve contributed mods to two packages that were rejected because I hadn’t provided typing (and black formatting, but that’s a different subject). I’ve reluctantly done so. And while I *hated* it because of the unreadability I _do_ like the outcome: I changed some of the APIs because they were doing things “my way”, but that was really pretty impossible to explain to the typing system. The modified APIs are arguably cleaner. I’m not yet at the point where I’m going to type all the packages and other stuff I maintain, but I _am_ contemplating doing it, eventually, maybe, if I find the time, procrastination willing, …. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/52PLPW735QJD235BEKOBCHJREI6MWBRT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
Indeed, there needs to be a way to get back and forth from the little typing
language to Python and back.
That’s why I suggested the t-string format: in analogy to f-strings you could
use {expression} constructs in there that would be evaluated in the normal
Python environment (and syntax).
For the sake of argument lets assume for now that the little language uses
- a : b to be equivalent to Mapping[a, b]
- [a] to be Sequence[a]
- (a, b) being Tuple[a, b]
- (a, b) -> c being Callable,
- *a being Iterable[a]
- ?a being Optional[a]
Then your example would become something like
T = TypeVar(’T’)
Data = t’str : [(int, T)]’
Factory = t’(int, *str) -> ?[Data(T)]’
And note that I’m making up the syntax as I’m typing. Maybe it’s much better to
use keywords (like optional, iterable) in stead of symbols).
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
> On 8 Jan 2022, at 11:32, Serhiy Storchaka wrote:
>
> 08.01.22 01:59, jack.jan...@cwi.nl пише:
>>> If I can make a wild suggestion: why not create a little language for
>>> type specifications?
>
> We need a way to define aliases. For example, write:
>
> Data = Mapping[str, Sequence[Tuple[int, T]]]
> Factory = Callable[[int, Iterable[str]], Optional[list[Data[T
>
> def get_foo_factory(type: str, id: int) -> Factory[Foo]: ...
>
> instead of
>
> def get_foo_factory(type: str, id: int) -> Callable[[int,
> Iterable[str]], Optional[list[Mapping[str, Sequence[Tuple[int,
> Foo]]: ...
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/42A5UC246FL2C57WSXP5Y2DANFGTG4PU/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WAGSHSCI7TULRYM367S2SXWJOVJIHLKK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Suggestion: a little language for type definitions
I posted this suggestion earlier in the callable type syntax discussion, at
which point it was completely ignored. Possibly because it’s a really stupid
idea, but let me post it again on the off chance that it isn’t a stupid idea
but was overlooked.
> If I can make a wild suggestion: why not create a little language for type
> specifications?
>
> If you look at other programming languages you’ll see that the “type
> definition sub-language” is often completely different from the “execution
> sub-language”, with only some symbols in common and used in vaguely related
> ways. `bool (*myfuncptr)(int, float*)` uses a completely different set of
> syntactic rules than `rv = (*myfunptr)(*myintptr, )`. So with some
> grains of salt you could say that C is comprised of a declarative typing
> sublanguage and an imperative execution sublanguage.
And an even better example is Pascal, which uses a set of syntactic constructs
for typing that are completely different from the execution statement syntax:
`var a : array[1..10] of real` looks very different from `a[1]`, where C `float
a[10]` looks pretty similar to `a[10]`.
The next bit of my original email is another wild idea, the previous bit
doesn’t depend on it really. I can imagine completely different ways of doing a
typing sublanguage:
> Python typing uses basically a subset of the execution expression syntax as
> its declarative typing language.
>
> What if we created a little language that is clearly flagged, for example as
> t”….” or t’….’? Then we could simply define the typestring language to be
> readable, so you could indeed say t”(int, str) -> bool”. And we could even
> allow escapes (similar to f-strings) so that the previous expression could
> also be specified, if you really wanted to, as t”{typing.Callable[[int, str],
> bool}”.
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/26JB6YIPWXUSTQSXTVSZMUS6FM4RZBJA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on Callable Type Syntax
If I can make a wild suggestion: why not create a little language for type
specifications?
If you look at other programming languages you’ll see that the “type definition
sub-language” is often completely different from the “execution sub-language”,
with only some symbols in common and used in vaguely related ways. `bool
(*myfuncptr)(int, float*)` uses a completely different set of syntactic rules
than `rv = (*myfunptr)(*myintptr, )`. So with some grains of salt you
could say that C is comprised of a declarative typing sublanguage and an
imperative execution sublanguage.
Python typing uses basically a subset of the execution expression syntax as its
declarative typing language.
What if we created a little language that is clearly flagged, for example as
t”….” or t’….’? Then we could simply define the typestring language to be
readable, so you could indeed say t”(int, str) -> bool”. And we could even
allow escapes (similar to f-strings) so that the previous expression could also
be specified, if you really wanted to, as t”{typing.Callable[[int, str], bool}”.
Jack
> On 7 Oct 2021, at 18:41, S Pradeep Kumar wrote:
>
> Hello all,
>
> Typing-sig has been discussing user-friendly syntax for the type used to
> represent callables. [1] Since this affects the Python language syntax, we
> wanted to get some high-level feedback from you before putting up a detailed
> PEP.
>
> TL;DR: We want to propose syntax for Callable types, e.g., `(int, str) ->
> bool` instead of `typing.Callable[[int, str], bool]`. Questions: 1. Are there
> concerns we need to keep in mind about such a syntax change? 2. Should we
> propose syntax for additional features in the same PEP or in a future PEP?
>
>
> # Motivation
>
> Guido has pointed out that `Callable` is one of the most frequently used type
> forms but has the least readable syntax. For example, say we have a callback
> `formatter` that accepts a record and a list of permissions:
>
> ```python
> def print_purchases(
> user,
> formatter, # <-- callback
> ):
> <...>
> output = formatter(record, permissions)
> print(output)
> ```
>
> To give it a type, we currently have to write:
>
> ```python
> from typing import Callable
>
> def print_purchases(
> user: User,
> formatter: Callable[[PurchaseRecord, List[AuthPermission]],
> FormattedItem] # Hard to read.
> ) -> None:
>
> <...>
> output = formatter(record, permissions)
> print(output)
> ```
>
> `Callable` can be hard to understand for new users since it doesn't resemble
> existing function signatures and there can be multiple square brackets. It
> also requires an import from `typing`, which is inconvenient. Around 40% of
> the time [2], users just give up on precisely typing the parameters and
> return type of their callbacks and just leave it as a blank Callable. In
> other cases, they don't add a type for their callback at all. Both mean that
> they lose the safety guarantees from typing and leave room for bugs.
>
> We believe that adding friendly syntax for Callable types will improve
> readability and encourage users to type their callbacks more precisely. Other
> modern, gradually-typed languages like TypeScript (JS), Hack (PHP), etc. have
> special syntax for Callable types.
>
> (As a precedent, PEP 604 recently added clean, user-friendly syntax for the
> widely-used `Union` type. Instead of importing `Union` and writing `expr:
> Union[AddExpr, SubtractExpr], we can just write `expr: AddExpr |
> SubtractExpr`.)
>
>
> # Proposal and Questions
>
> We have a two-part proposal and questions for you:
>
> 1. Syntax to replace Callable
>
> After a lot of discussion, there is strong consensus in typing-sig about
> adding syntax to replace Callable. So, the above example would be written as:
> ```python
> def print_purchases(
> user: User,
> formatter: (PurchaseRecord, List[AuthPermission]) -> FormattedItem,
> ) -> None:
>
> <...>
> output = formatter(record, permissions)
> print(output)
> ```
> This feels more natural and succinct.
>
> Async callbacks currently need to be written as
> ```
> from typing import Callable
>
> async_callback: Callable[[HttpRequest], Awaitable[HttpResponse]]
> ```
>
> With the new syntax, they would be written as
> ```
> async_callback: async (HttpRequest) -> HttpResponse
> ```
> which again seems more natural. There is similar syntax for the type of
> decorators that pass on *args and **kwargs to the decorated function.
>
> Note that we considered and rejected using a full def-signature syntax like
>
> (record: PurchaseRecord, permissions: List[AuthPermission], /) ->
> FormattedItem
>
> because it would be more verbose for common cases and could lead to subtle
> bugs; more details in [3].
>
> The Callable type is also usable as an expression, like in type aliases
> `IntOperator = (int, int) -> int` and `cast((int) -> int, f)` calls.
>
> **Question 1**: Are there
[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API
> On 26 Sep 2021, at 04:09, MRAB wrote: > > On 2021-09-26 00:14, jack.jan...@cwi.nl wrote: >> I think we really need to come up with some scheme whereby extension >> packages become more long-lived than a single Python release... > You mean, something like the Python ABI (PEP 384, Stable Application Binary > Interface)? And Steven D”Aprano also mentioned the stable ABI. The problem with the stable ABI is that very few developers are targeting it. I’m not sure why not, whether it has to do with incompleteness of the ABI, or with issues targeting it easily and your builds and then having pip/PyPI do the right things with wheels and all that. I’ve been on the capi-sig mailing list since its inception in 2007, but the discussions are really going over my head. I don’t understand what the problems are that keep people from targeting the stable ABI (or the various other attempts at standardising extensions over Python versions). > On 26 Sep 2021, at 06:21, Steven D'Aprano wrote: > > Do you have a reason to think that it is in danger in some way? Some > factor that didn't apply equally in 2001 and 2011 as it does in 2021? Yes, very much so. Wheels. Before we had wheels there were very few packages that were distributed in binary form, the NumPy family and the various GUI toolkits are the only ones that come to mind, and they had very active developer communities that tracked Python releases. Wheels are absolutely wonderful, but the downside is that everyone has come to depend on them. Before wheels, extension modules were often optional, in that many packages would provide their basic functionality in pure Python, and then have some performance-enhancing or functionality-extending optional extension modules. Wheels have obviated the need for that. So now everything depends on extension modules (and on external packages that depend on extension modules, and so on). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/O5WTFG5WER7PALCYFCDJLP4VWYUWMAPS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API
> On 26 Sep 2021, at 05:49, Nathaniel Smith wrote: > > On Sat, Sep 25, 2021 at 5:40 PM wrote: >> PyPI packages and wheels are targeted to specific Python versions, which >> means that any project that depends on some of the larger extension packages >> (of which there are many, and many of which are must-have for many projects) >> now start lagging Python versions by years, because somewhere deep down in >> the dependency graph there is something that is still stuck at Python 3.8 >> (for example). > > Can you give some examples of the packages you're thinking of, that > are prominent/must-have and stuck on years-old Pythons? Open3D is an example. Will finally move to Python 3.9 some time the coming month. Its dependency graph contains about 70 other packages. In this specific case, the underlying problem was that TensorFlow was stuck at 3.8. The TensorFlow codebase got ported in November 2020, then released early 2021. Then Open3D included the new Tensorflow (plus whatever else needed to be adapted) in their codebase in May. They’re now going through their release schedule, and their 0.14 release should be up on PyPI soon. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PJYUB2R4VB7H4UBFQ6464OAKFAXBSRJQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Worried about Python release schedule and lack of stable C-API
I’m getting increasingly worried about the future of Python, and those worries have been exacerbated by the new yearly release rhythm, and the lack of a stable C-API that is full enough to entice extension writers to use it. PyPI packages and wheels are targeted to specific Python versions, which means that any project that depends on some of the larger extension packages (of which there are many, and many of which are must-have for many projects) now start lagging Python versions by years, because somewhere deep down in the dependency graph there is something that is still stuck at Python 3.8 (for example). I fully understand that 3.8 is good enough for the developers of that package, and that they have more pressing things to do than porting to 3.9 or 3.10, but it now keeps any project or package that depends on their software on 3.8 as well. And I also fully understand that some other developer who creates a new package that is essential to my application only targets the current Python release, or maybe one release back, but now if I need both the new package and and older one I’m up the well-known creek without a paddle. Building packages from source has become pretty much impossible nowadays, especially if your project is multi-platform and needs to interface to specific hardware, and you want to do the right thing with CI/CD builds and all that. On Linux/MacOS you have a chance when you try to specify all the dependencies for third party libraries and what not, but on Windows you’re dead in the water. And that is assuming you have the time and are smart enough to back port the new package to the old Python release, or the old package to the new Python release (and for the latter there’s probably a good reason why the developers haven’t done so already). Before you know it you have to install a couple of graphics card APIs for some obscure AI feature used by something you’ve never heard of, Cython for something else, and obscure vendor libraries for something else again. I think we really need to come up with some scheme whereby extension packages become more long-lived than a single Python release... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7ALUHJBJCZGFGXHK6TTDDR3ST4YVSAWR/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Tracker cleanup report
On 16-Feb-2009, at 20:40 , Daniel (ajax) Diniz wrote: There are about 20 Mac-related, 24 invalid/outdated and four IRIX issues on the 'will be closed unless someone voices disagreement' queue, so we have a good chance of totaling a hundred closed issues in ten days. I had a cursory look at these issues as they came by, and I didn't see any that struck me as still being relevant. -- Jack Jansen, jack.jan...@cwi.nl, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue
On 30-Sep-2008, at 23:42 , Martin v. Löwis wrote: It's the other way 'round: On Windows, Unicode file names are the natural choice, and byte strings have limitations. In a sense, Windows got it right - but then, they started later. Unix missed the opportunity of declaring that all file APIs are UTF-8 (except for Plan-9 and OS X, neither being true Unix). How does windows (and Python on windows) handle NFC versus NFD issues? Can I have two files called ümlaut.txt, one in NFD and one NFC form? And are both of those representable on the Python side (i.e. can they both be returned from listdir() and passed to open())? CIf I compare these two filenames, do they compare differently? -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue
On 1-Oct-2008, at 00:32 , Martin v. Löwis wrote: How does windows (and Python on windows) handle NFC versus NFD issues? That's left to the application. Can I have two files called ümlaut.txt, one in NFD and one NFC form? Yes, you can. It sounds confusing, but only in a theoretical way. You never have combining characters on Windows (at least, I don't). The keyboard input defaults to NFC, and users normally don't type file names, anyways, except when creating the files - later, they just use the mouse to indicate what file they want to act on. And are both of those representable on the Python side (i.e. can they both be returned from listdir() and passed to open())? Certainly! CIf I compare these two filenames, do they compare differently? Certainly! Actually, that all sounds pretty non-confusing to me:-) So, normal users will always have the one form, and if by chance they get the other form they can still use the file. Also from Python, even when doing listdir() and then open(), everything will work just as expected. That there are two files that have a similar visual representation is not too bad, the same happens with ellipses versus dot-dot-dot and many other cases. Which means the only problem area left is unix filesystems (whether on Linux or mounted remotely on MacOS or whatever), where filenames are really byte strings with only / and nul illegal. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?
On 19-Aug-2008, at 19:28 , Bill Janssen wrote: My understanding is that if there is a system Python, you shouldn't change it. Ever. Huge, big, honkin' +1 from me on that. Besides, for a system Python, you want your distribution to manage packages, not setuptools, otherwise you confuse -- and probably break -- your system. I find this discussion fascinating. I install new packages into my system Python all the time, with /usr/bin/python setup.py install, and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, roman, setuptools, and SSL installed in the Leopard machine I'm writing from. They don't wind up in /System/Library/.../site-packages/, they wind up in /Library/Python/2.5/site-packages/, which is sort of the right place, from an Apple point of view. I do this on lots of Macs -- I've got a regular posse of them at work. And I've never had any problems with it. Same here: if have yet to see adverse consequences of installing third party packages into system Python. And now that Apple is distributing fairly current versions of things like PyObjC there's even little reason to build my own copy of Python. I have one on disk, but I find that I use the system Python for almost everything. Fink (and to a lesser extent MacPorts) I don't touch with a 10 feet pole: too often I've created software for distribution only to find that it somehow, behind my back, was linked against a dynamic library that I had installed locally through it. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
On 12-feb-2007, at 0:45, Ben North wrote: self.(method_name) = self.metadata.(method_name) I like the functionality, but I don't like the syntax, to me it looks too much like a method call. To me self.[method_name] = self.metadata.[method_name] looks better: what we're doing here is more like dictionary lookup than calling functions. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file(file)
On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
On 1/12/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
I'm not sure I understand the use case; I don't believe I've ever felt
the need for this.
I have oodles of routines of the form
def foo(thefile):
if type(thefile) == str: thefile = open(thefile)
or
if not hasattr(thefile, 'read'): thefile = open(thefile)
or something similar.
We should also consider the semantics in more detail. Should the seek
position be shared between the two objects? What about buffering?
That's definitely the hard part. But it's somewhat similar to
normal mutable objects which are (I think always, right?) shallow
copied when used in a constructor.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 3-Jan-2007, at 23:17 , Gregory P. Smith wrote: +1 on using the python/*.h subdirectory. I'm a bit concerned about the python/*.h: could it cause trouble in combination with Apple's framework naming convention (#include QuickTime/Quicktime.h magically gets the header out of the quicktime framework) and the case-insensitiveness of the Mac filesystem? Will #include python/blabla.h always find that file along the -I paths, and not somehow accidentally start looking for /Library/Framework/Python.framework/ Headers/blabla.h? -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 28-nov-2006, at 22:05, Guido van Rossum wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) +1. We've been running into this problem on the Mac since Apple started shipping Python. There's another standard place that is searched on MacOS: a per-user package directory ~/Library/Python/2.5/site-packages (the name site- packages is a misnomer, really). Standardising something here is less important than for vendor-packages (as the effect can easily be gotten by adding things to PYTHONPATH) but it has one advantage: distutils and such could be taught about it and provide an option to install either systemwide or for the current user only. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
Would it be possible to make the data-type objects subclassable, with the subclasses being able to override the equality test?The range of data types that you've specified in the PEP are good enough for most general use, and probably for NumPy as well, but someone already came up with the example of image formats, which have their whole own range of data formats. I could throw in audio formats (bits per sample, excess-N or signed or ulaw samples, mono/stereo/5.1/etc, order of the channels), and there's probably a whole slew of other areas that have their own sets of formats.If the datatype objects are subclassable, modules could initially start by adding their own formats. So, the "jackaudio" and "jillaudio" modules would have distinct sets of formats. But then later on it should be fairly easy for them to recognize each others formats. So, jackaudio would recognize the jillaudio format "msdos linear pcm" as being identical to its own "16-bit excess-32768".Hopefully eventually all audio module writers would get together and define a set of standard audio formats. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The lazy strings patch
On 23-Oct-2006, at 16:58 , Larry Hastings wrote:I genuinely don't know how many external Python extension modules are well-behaved in this regard. But in case it helps: I just checked PIL, NumPy, PyWin32, and SWIG, and all of them were well-behaved. Apart from stringobject.c, there was exactly one spot in the Python source tree which made assumptions about the structure of PyStringObjects (Mac/Modules/macos.c). It's in the block starting with the comment "This is a hack:". Note that this is unfixed in my patch, so just now all code using that self-avowed "hack" will break.As the author of that hack, that gives me an idea for where you should look for code that will break: code that tries to expose low-level C interfaces to Python. (That hack replaced an even earlier worse hack, that took the id() of a string in Python and added a fixed number to it to get at the address of the string, to fill it into a structure, blush).Look at packages such as win32, PyObjC, ctypes, bridges between Python and other languages, etc. That's where implementors are tempted to bend the rules of Official APIs for the benefit of serious optimizations. --Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jackIf I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segfault in python 2.5
On 18-Oct-2006, at 22:08 , Michael Hudson wrote: Unfortunately, I've been attempting for hours to reduce the problem to a completely self-contained script, but it is resisting my efforts due to timing problems. Has anyone ever tried to use helgrind (the valgrind module, not the heavy metal band:-) on Python? -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OT: How many other people got this spam?
I was wondering: how many other people who maintain websites (well: maintain might be a bit of a misnomer in my case:-) related to Python have also got this spam? Begin forwarded message: From: Snake Tracks [EMAIL PROTECTED] Date: October 1, 2006 21:21:45 GMT+02:00 To: Cwi [EMAIL PROTECTED] Subject: Special Invitation for cwi.nl from Snake Tracks Fellow Website Owner/Operator; As of September 29th, 2006 we will be launching what is soon to be the worlds largest snake enthusiast website. The website contains valuable information for all those interested in snakes including care sheets, species information and identification, breeding information, and an extensive list of snake specific forums. We welcome you to visit our website and join our community of snake enthusiasts worldwide. Currently we are browsing through Google and other major search engines looking for websites we feel would make good link partners. I have personally come across your site and think that exchanging links could benefit both of our businesses. By linking to us you will receive a reciprocal link and be showcased in front of all our visitors. If you are interested in this partnership please add one of the following text links or banners to a high traffic area on your website: 1) Snake Tracks - The Worlds Largest Snake Enthusiast Website. Visit our site for care sheets, species information, field herping information, breeding, captive care, and our extensive list of snake enthusiast forums. 2) Snake Tracks Forums - Visit the Worlds Largest Collection of Snake Enthusiast forums including our field herping, captive care, habitat design, and regional forums. 3) Snake Care Sheets - Visit the Worlds Largest Snake Enthusiast Website. Forums, Care Sheets, Field Herping, Species information and more. You may also visit our link page to choose from several banner images and text links. Once you have linked to our website, fill out the form and we will add your site to our directory. http://www.snaketracks.com/linktous.html I look forward to hearing from you in regards to this email. Please allow up to 24 hours for a response as we are currently receiving extremely large amounts of email. Sincerely; Blair Russell - Snaketracks.com -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
On 29-sep-2006, at 4:24, Greg Ewing wrote: An example of a good way to do it is the original Inside Macintosh series. Each chapter started with a narrative-style About this module kind of section, that introduced the relevant concepts and explained how they fitted together, without going into low-level details. Then there was a Reference section that systematically went through and gave all the details of the API. Yep, this is exactly what I often miss in the Python library docs. The module intro sections often do contain the executive summary of the module, so that you can quickly see whether this module could indeed help you solve the problem at hand. But then you go straight to descriptions of classes and methods, and there is often no info on how things are plumbed together, both within the module (how the classes relate to each other) and more globally (how this module relates to others, see also). A similar thing occurs one level higher in the library hierarchy: the section introductions are little more that a list of all the modules in the section. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Just wondering: is it a good idea in the first place to create a universal 32/64 bit Python on MacOSX? On MacOS you don't pay a penalty or anything for running in 32-bit mode on any current hardware, so the choice of whether to use 32 or 64 bits really depends on the application. A single Python interpreter that can run in both 32 and 64 bit mode would possibly make this more difficult rather than easier. I think I'd prefer a situation where we have python32 and python64 (with both being ppc/ intel fat) and python being a symlink to either, at the end-users' discretion. For extension modules it's different, though: there it would be nice to be able to have a single module that could load into any Python (32/64 bit, Intel/PPC) on any applicable MacOSX version. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Thanks to all for a rather insightful discussion, it's always fun to
learn that after 28 years of C programming the language still has
little corners that I know absolutely nothing about:-)
Practically speaking, though, I've adopted MAL's solution for the
time being:
/* The keyword array changed to const char* in Python 2.5 */
#if PY_VERSION_HEX = 0x0205
# define Py_KEYWORDS_STRING_TYPE const char
#else
# define Py_KEYWORDS_STRING_TYPE char
#endif
...
static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
...
if (!PyArg_ParseTupleAndKeywords(args,kws,format,kwslist,a1))
goto onError;
At least this appears to work...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mac memory leaks
On 3 Jan 2006, at 08:58, Neal Norwitz wrote: I had a friend run regrtest -L on Mac OSX a while ago. There are several memory leaks which still appear to be an issue. There are a bunch of leaks reported from putenv which I'm not sure how to fix The attached patch should correct one of the problems. Can someone with a Mac test it? I'll add to SF later if I don't get a response. n -- I'm not sure about how to fix these or if they are real problems: Leak: 0x02541470 size=368 instance of 'NSCFData' Call stack: call_function | ici_ICFindPrefHandle | ICFindPrefHandle | OpaqueICInstance::FindPrefHandle(ICKeyInfo const, unsigned long*, char**) | OpaqueICInstance::GetPref(ICKeyInfo const, long, void*, long*, unsigned long*) | OpaqueICInstance::GetPrefCore(ICKeyInfo const, long, void*, long*, unsigned long*) | OpaqueICInstance::LazyLoad() | ICCFPrefWrapper::ContainsPrefs() | ICCFPrefWrapper::GetPrefDictionary() | fetchXMLValue | _loadXMLDomainIfStale | _CFPropertyListCreateFromXMLData | __CFTryParseBinaryPlist | __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject | __CFDataInit | _CFRuntimeCreateInstance | CFAllocatorAllocate This is somewhere down in the Internet Config builtin module, which would point to the webbrowser library module. My guess is that it's a singleton leak. Leak: 0x02506640 size=256 Call stack: call_function | do_call | PyObject_Call | parser_st2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | PyTuple_New | _PyObject_GC_NewVar | _PyObject_GC_Malloc | PyObject_Malloc | new_arena No idea. There don't seem to be any mac-specific modules involved... Leak: 0x0118ad10 size=80 Call stack: call_function | AE_AECreateDesc | AECreateDesc | operator new(unsigned long) Hmm, the first candidates here would be test_aepack and test_scriptpackages, but neither one has an obvious leak (on cursory inspection). And actually, if there was a leak problem in either I would expect more than one AEDesc to be leaked. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposal: can we have a python-dev-announce mailing list?
As people may have noticed (or possibly not:-) I've been rather inactive on python-dev the last year or so, due to being completely inundated with other work. Too bad that I've missed all the interesting discussions on Python 3000, but I'm bound to catch up some time later this year:-). BUT: what I also missed are all the important announcements, such as new releases, the switch to svn, and a couple more (I think). I know I would be much helped with a moderated python-dev-announce mailing list, which would be only low-volume, time-critical announcements for people developing Python. Even during times when I am actively following python-dev it would be handy to have important announcements coming in in a separate mailbox in stead of buried under design discussions and such... -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: can we have a python-dev-announce mailing list?
On 3-nov-2005, at 22:36, Oleg Broytmann wrote: On Thu, Nov 03, 2005 at 10:29:37PM +0100, Jack Jansen wrote: I know I would be much helped with a moderated python-dev-announce mailing list, which would be only low-volume http://www.google.com/search?q=python-dev+summary+site% 3Amail.python.org Hmm. I wouldn't mind if it was push in stead of pull, I wouldn't mind if it was in the right order, and I wouldn't mind if itwas more concise:-) But: I'll just wait to see whether more people chime in that they'd like this, or that I'm alone... -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Tools/bgen/bgen bgenGenerator.py, 1.17, 1.18 bgenObjectDefinition.py, 1.29, 1.30 bgenType.py, 1.15, 1.16 bgenVariable.py, 1.6, 1.7 scantools.py, 1.37
On 24-jun-2005, at 21:46, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Tools/bgen/bgen In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18095/Tools/ bgen/bgen Modified Files: bgenGenerator.py bgenObjectDefinition.py bgenType.py bgenVariable.py scantools.py Log Message: Normalize whitespace to avoid offending Bug Day volunteers. Argh, sorry... I thought I had all my machines educated to do tab expansion for Python, but apparently not... -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: marshal / unmarshal
On 14-apr-05, at 15:08, David Robinow wrote: On 4/11/05, Tim Peters [EMAIL PROTECTED] wrote: Heh. I have a vague half-memory of _some_ box that stored the two 4-byte words in an IEEE double in one order, but the bytes within each word in the opposite order. It's always something ... I believe this was the Floating Instruction Set on the PDP 11/35. The fact that it's still remembered 30 years later shows how unusual it was. I think it was actually logical, because all PDP-11s (there were 2 or 3 FPU instructionsets/architecture in the family IIRC) stored 32 bit integers in middle-endian (high-order word first, but low-order byte first). But note that neither of the PDP-11 FPUs were IEEE, that was a much later invention. At least, I didn't come across it until much later:-) -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems with definition of _POSIX_C_SOURCE
On a platform I won't mention here I'm running into problems compiling Python, because of it defining _POSIX_C_SOURCE. It turns out that on this platform the definition causes all sorts of declarations in sys/types.h to be skipped (presumably because they're not official Posix identifiers), which in turn causes platform-specific headers to fail. The comment in pyconfig.h suggests that defining _POSIX_C_SOURCE may enable certain features, but the actual system headers appear to work the other way around: it seems that defining this will disable features that are not strict Posix. Does anyone know what the real meaning of this define is? Because if it is the former then Python is right, but if it is the latter Python really has no business defining it: in general Python isn't 100% posix-compliant because it'll use all sorts of platform-dependent (and, thus, potentially non-posix-compliant) code... This problem is currently stopping Python 2.4.1 to compile on this platform, so if anyone can provide any insight that would be very helpful... -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is msvcr71.dll re-redistributable?
On 3 Feb 2005, at 02:01, Phillip J. Eby wrote: Sounds like this puts all Python users in the clear, since Python is the Licensee Software in that case. So, anybody can distribute msvcr71 as part of Python. OTOH, the other wording sounds like Python itself has to have a click-wrap, tear-open, or signature EULA! IOW, the EULA appears to prohibit free distribution of the runtime with a program that has no EULA. So, in an amusing turn of events, the EULA actually appears to forbid the current offering of Python for Windows, since it does not have such a EULA. That was also my conclusion last year:-( But at least Python can still be distributed without msvcr71, putting the burden of obtaining it on the end user, because of Python's license. In another project we're using GPL, and careful reading (disclaimer: IANAL) has not convinced me that GPL and the EULA are compatible. Actually, I have this vague feeling that the MSVC 7 EULA (plus the fact that MS isn't shipping msvcr71.dll with Windows) might have been drafted specifically to be incompatible with the clause in GPL that doesn't allow you to link against third party libraries unless they're part of the OS. What we've done in that project is link with msvcr71.dll, but not include it in the installer. I think that we could (theoretically) still be dragged into court by the FSF, but at least not by Microsoft. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unix line endings required for PyRun* breaking embedded Python
On 21 Jan 2005, at 08:18, Stuart Bishop wrote: Just van Rossum wrote: Skip Montanaro wrote: Just re.sub([\r\n]+, \n, s) and I think you're good to go. I don't think that in general you want to fold multiple empty lines into one. This would be my prefered regex: s = re.sub(r\r\n?, \n, s) Catches both DOS and old-style Mac line endings. Alternatively, you can use s.splitlines(): s = \n.join(s.splitlines()) + \n This also makes sure the string ends with a \n, which may or may not be a good thing, depending on your application. Do people consider this a bug that should be fixed in Python 2.4.1 and Python 2.3.6 (if it ever exists), or is the resposibility for doing this transformation on the application that embeds Python? It could theoretically break something: a program that uses unix line-endings but embeds \r or \r\n in string data. But this is rather theoretical, I don't think I'd have a problem with fixing this. The real problem is: who will fix it, because the fix isn't going to be as trivial as the Python code posted here, I'm afraid... -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
On 7 Jan 2005, at 11:08, Bob Ippolito wrote: 10.3 or later. For older OSX releases (either because you build Python on 10.2 or earlier, or because you've set MACOSX_DEPLOYMENT_TARGET to a value of 10.2 or less) we use the old behaviour of linking with -framework Python. Wouldn't it be better to link with the actual dylib inside the framework on 10.2? Otherwise you can no longer build 2.3 extensions after you've installed 2.4. It would certainly be better to do this for 10.2. This patch implements the proposed direct framework linking: http://python.org/sf/1097739 Looks good, I'll incorporate it. And as I haven't heard of any showstoppers for the -undefined dynamic_lookup (and Anthony seems to be offline this week) I'll put that in too. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote: The new solution is basically to go back to the Unix way of building an extension: link it against nothing and sort things out at runtime. Not my personal preference, but at least we know that loading an extension into one Python won't bring in a fresh copy of a different interpreter or anything horrible like that. This sounds good, except that it only works on OS X 10.3, right? What about older versions? 10.3 or later. For older OSX releases (either because you build Python on 10.2 or earlier, or because you've set MACOSX_DEPLOYMENT_TARGET to a value of 10.2 or less) we use the old behaviour of linking with -framework Python. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac questions
On 4 Jan 2005, at 11:41, Bob Ippolito wrote: And finally: Is there any other way to find the true spelling of a file except than a linear search with opendir()/readdir()/closedir() ? Yes, definitely. I'm positive you can do this with CoreServices, but I'm not sure it's portable to Darwin (not Mac OS X). I'm sure there is some Darwin-compatible way of doing it, but I don't know it off the top of my head. I'll try to remember to look into it if nobody else finds it first. I haven't used pure darwin, but I assume it has support for FSRefs, right? Then you could use FSPathMakeRef() to turn the filename into an FSRef, and then FSGetCatalogInfo() to get the true filename. -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
On 29-dec-04, at 4:35, Bob Ippolito wrote: This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == c++ and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) linker is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). Bah! Any suggestions as to what to do to get c++ compilation fixed? Also, could you point me to a readily available extension package that uses c++? -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
