Re: [Python-Dev] contributor to committer
Antoine Pitrou wrote: > Le Wed, 24 Feb 2010 12:13:10 +, Florent Xicluna a écrit : >> Hello, >> >> I am a semi-regular contributor for Python: I have contributed many >> patches since end of last year, some of them were reviewed by Antoine. > > Semi-regular is quite humble. You have been cranking out patches at a > higher frequency than almost any of us in the last 3 months. We are > exhausted of reviewing and (most of the time) committing your patches :) > (fortunately, your work happens to be of consistently good quality) Agreed, I'd been thinking this may be deserved based on the number of "patch by Florent Xicluna" commit messages I had seen go by on the checkins list. The usual caveats apply though: - don't get carried away with the privileges - even core devs still put patches on the tracker sometimes - if in doubt, ask for advice on python-dev (or IRC) - make sure to subscribe to python-checkins The last point covers the fact that most checkin messages will get an after-the-fact review from other developers and those comments usually go straight to the checkins list. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython
Maciej Fijalkowski wrote: > On Wed, Feb 24, 2010 at 6:35 AM, Nick Coghlan wrote: >> Tarek Ziadé wrote: >>> That makes me wonder : why don't we have a sys.implementation variable ? >>> (cython/jython/pypi), since we can have several values for cython in >>> sys.platform > > Hello. > > So I propose to have a sys.implementation which would have string > representation like "CPython" or "Jython" and have a couple of extra > attributes on that. I can think about a lot of attributes, however, > couple comes to mind as obvious. > > * supports_c_api - whether it can load and use CPython C modules > * gc_strategy - probably equals "refcounting" or not, useful for some people > * frame_introspection - This is mostly True for everybody except > IronPython which has it as an optional command line argument. Might be > useful to have it for some projects, unsure. > > What do you think? I think anything along these lines needs to be a PEP so that the developers of the different implementations all get a chance to comment and then have a firm standard to code to afterwards :) Christian was going to write one in the PEP 370 context, so it's worth following up with him to see if he ever got around to drafting anything. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
Doug Hellmann wrote: > We've recently run into an issue with subprocess on Solaris, as > described (by an earlier reporter) in issue #7242. The patch there > solves our problem, and has been verified to work by other users as > well. What's the status of the ticket? Is there anything I can do to > help move it forward to be included in a patch release for 2.6? The usual 5-for-one deal applies: review five issues, and I'll review that one (with more energy than at the moment). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
On Feb 25, 2010, at 2:34 PM, Martin v. Löwis wrote: Doug Hellmann wrote: We've recently run into an issue with subprocess on Solaris, as described (by an earlier reporter) in issue #7242. The patch there solves our problem, and has been verified to work by other users as well. What's the status of the ticket? Is there anything I can do to help move it forward to be included in a patch release for 2.6? The usual 5-for-one deal applies: review five issues, and I'll review that one (with more energy than at the moment). I have commit access, can I just check in the patch? Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
Le Thu, 25 Feb 2010 14:38:42 -0500, Doug Hellmann a écrit : > > I have commit access, can I just check in the patch? If you are sure of yourself, you can. But in this case see my comment on the tracker. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
Doug Hellmann wrote: > > On Feb 25, 2010, at 2:34 PM, Martin v. Löwis wrote: > >> Doug Hellmann wrote: >>> We've recently run into an issue with subprocess on Solaris, as >>> described (by an earlier reporter) in issue #7242. The patch there >>> solves our problem, and has been verified to work by other users as >>> well. What's the status of the ticket? Is there anything I can do to >>> help move it forward to be included in a patch release for 2.6? >> >> The usual 5-for-one deal applies: review five issues, and I'll review >> that one (with more energy than at the moment). > > I have commit access, can I just check in the patch? If you think it's good, and feel comfortable with it, etc.: sure. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of issue #7242
On Feb 25, 2010, at 2:47 PM, Antoine Pitrou wrote: Le Thu, 25 Feb 2010 14:38:42 -0500, Doug Hellmann a écrit : I have commit access, can I just check in the patch? If you are sure of yourself, you can. But in this case see my comment on the tracker. OK, good point. I'll see about a test or two and post an update to the ticket. Thanks, Doug ___ Python-Dev mailing list [email protected] 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__
On Feb 03, 2010, at 01:07 PM, Antoine Pitrou wrote: >Well, I don't think we need another transition... Just keep __file__ for the >source file, and add a __cache__ or __compiled__ attribute for the compiled >file(s). >Since there might be several compiled files for a single source file (for >example, a .pyc along with a JITted native .so), __cache__ should probably be >a tuple rather than a string. I'm going to call the attribute __cached__ and leave its contents implementation defined. For CPython it will be the path to the pyc file if it exists (or was written), or the path to where the pyc file /would/ exist if the source lives on a read-only file system or -B/$PYTHONDONTWRITEBYTECODE is set. For alternative implementations of Python that compose modules from multiple sources, __cached__ can be a tuple. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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__
On Feb 03, 2010, at 12:42 PM, Brett Cannon wrote: >So what happens when only bytecode is present? We discussed this at Pycon and agreed that we will not support source-less deployments by default. The source file must exist or it will be an ImportError. This does not mean source-less deployments are not possible though. To support this use case, you'd have to write a custom import hook. We may write one as part of the PEP 3147 implementation. Contributions are of course welcome! -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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__
Barry Warsaw wrote: We discussed this at Pycon and agreed that we will not support source-less deployments by default. The source file must exist or it will be an ImportError. This does not mean source-less deployments are not possible though. To support this use case, you'd have to write a custom import hook. What I don't like this idea at all. I object to being forced to jump through an obscure hoop to do something that's been totally straightforward until now. -- Greg ___ Python-Dev mailing list [email protected] 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__
On 25/02/2010 23:56, Greg Ewing wrote: Barry Warsaw wrote: We discussed this at Pycon and agreed that we will not support source-less deployments by default. The source file must exist or it will be an ImportError. This does not mean source-less deployments are not possible though. To support this use case, you'd have to write a custom import hook. What I don't like this idea at all. I object to being forced to jump through an obscure hoop to do something that's been totally straightforward until now. I thought we agreed at the language summit that if a .pyc was in the place of the source file it *could* be imported from - making pyc only distributions possible. As the pyc files are in the __pycache__ (or whatever) directory by default they *won't* be importable without the source files. A pyc only distribution can easily be created though with this scheme. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] 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__
On Thu, Feb 25, 2010 at 3:50 PM, Michael Foord wrote: > On 25/02/2010 23:56, Greg Ewing wrote: >> >> Barry Warsaw wrote: >> >>> We discussed this at Pycon and agreed that we will not support >>> source-less >>> deployments by default. The source file must exist or it will be an >>> ImportError. >>> >>> This does not mean source-less deployments are not possible though. To >>> support this use case, you'd have to write a custom import hook. >> >> What >> >> I don't like this idea at all. I object to being forced to >> jump through an obscure hoop to do something that's been >> totally straightforward until now. >> > I thought we agreed at the language summit that if a .pyc was in the place > of the source file it *could* be imported from - making pyc only > distributions possible. As the pyc files are in the __pycache__ (or > whatever) directory by default they *won't* be importable without the source > files. A pyc only distribution can easily be created though with this > scheme. That's also my recollection. Basically, for .pyc-only modules, nothing changes. PS. I still prefer __compiled__ over __cached__ but I don't feel strong about it. > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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__
Michael Foord wrote: I thought we agreed at the language summit that if a .pyc was in the place of the source file it *could* be imported from - making pyc only distributions possible. Ah, that's okay, then. Sorry about the panic! -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3188: Implementation Questions
Hi All,
Recently some discussion began in the issue 3132 thread (
http://bugs.python.org/issue3132) regarding
implementation of the new struct string syntax for PEP 3118. Mark Dickinson
suggested that I bring the discussion on over to Python Dev. Below is a
summary
of the questions\comments from the thread.
Unpacking a long-double
===
1. Should this return a Decimal object or a ctypes 'long double'?
2. Using ctypes 'long double' is easier to implement, but precision is
lost when needing to do arithmetic, since the value for cytpes 'long
double'
is converted to a Python float.
3. Using Decimal keeps the desired precision, but the implementation would
be non-trivial and architecture specific (unless we just picked a
fixed number of bytes regardless of the architecture).
4. What representation should be used for standard size and alignment?
IEEE 754 extended double precision?
Pointers
==
1. What is a specific pointer? For example, is '&d' is a pointer to a
double?
2. How would unpacking a pointer to a Python Object work out? Given an
address how would the appropriate object to be unpacked be determined?
3. Can pointers be nested, e.g. '&&d' ?
4. For the 'X{}' format (pointer to a function), is this supposed to mean a
Python function or a C function?
String Syntax
==
The syntax seems to have transcended verbal description. I think we
need to put forth a grammar. There are also some questions regarding
nesting
levels and mixing specifiers that could perhaps be answered more clearly by
having a grammar:
1. What nesting level can structures have? Arbitrary?
2. The new array syntax claims "multi-dimensional array of whatever
follows".
Truly whatever? Arrays of structures? Arrays of pointers?
3. How do array specifiers and pointer specifiers mix? For example,
would '(2, 2)&d' be a two-by-two array of pointers to doubles?
What about '&(2, 2)d'? Is this a pointer to an two-by-two array of
doubles?
An example grammar is contained in a diff against the PEP attached to this
mail. NOTE: I am *not* actually submitting a patch against the PEP. This
was just the clearest way to present the example grammar.
Use Cases
1. What are the real world use cases for these struct string extensions?
These should be fleshed out and documented.
-- Meador
pep-3118.diff
Description: Binary data
___
Python-Dev mailing list
[email protected]
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 3188: Implementation Questions
On approximately 2/25/2010 8:51 PM, came the following characters from the keyboard of Meador Inge: Hi All, Recently some discussion began in the issue 3132 thread (http://bugs.python.org/issue3132) regarding implementation of the new struct string syntax for PEP 3118. Mark Dickinson suggested that I bring the discussion on over to Python Dev. Below is a summary of the questions\comments from the thread. Unpacking a long-double === 1. Should this return a Decimal object or a ctypes 'long double'? 2. Using ctypes 'long double' is easier to implement, but precision is lost when needing to do arithmetic, since the value for cytpes 'long double' is converted to a Python float. 3. Using Decimal keeps the desired precision, but the implementation would be non-trivial and architecture specific (unless we just picked a fixed number of bytes regardless of the architecture). 4. What representation should be used for standard size and alignment? IEEE 754 extended double precision? Because of 2 (lossy, dependency), and 3 (non-trivial, architecture specific), neither choice in 1 seems appropriate. Because of the nature of floats, because the need for manipulation may vary between applications, and because the required precision may vary between applications, I would recommend adding a "CLongDoubleStructWrapper" class (a better name would be welcome), which would copy the architecture-specific byte-stream and preserve it. If converted back to a struct, it would be lossless. If manipulation is required, the class could have converters to Python float (lossy), and Decimal of user-specifiable precision (punt the precision question to the application developer, who should know the needs of the application, and the expected platforms). It might be reasonable to handle double and float similarly, at least as an option. On the other hand, if there can be options, perhaps they could be given when supplying the struct string syntax except the application may only wish to manipulate a few of the long double values, and converting the others would be wasteful. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list [email protected] 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 3188: Implementation Questions
Meador Inge schrieb: > Hi All, > > Recently some discussion began in the issue 3132 thread ( > http://bugs.python.org/issue3132) regarding > implementation of the new struct string syntax for PEP 3118. Mark Dickinson > suggested that I bring the discussion on over to Python Dev. Below is a > summary > of the questions\comments from the thread. > > Unpacking a long-double > === > > 1. Should this return a Decimal object or a ctypes 'long double'? > 2. Using ctypes 'long double' is easier to implement, but precision is > lost when needing to do arithmetic, since the value for cytpes 'long > double' > is converted to a Python float. > 3. Using Decimal keeps the desired precision, but the implementation would > be non-trivial and architecture specific (unless we just picked a > fixed number of bytes regardless of the architecture). > 4. What representation should be used for standard size and alignment? > IEEE 754 extended double precision? A variant of 2. would be to unpack into a ctypes 'long double', and extend the ctypes 'long double' type to retrive the value as Decimal instance, in addition to the default conversion into a Python float. -- Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
