Re: [Python-Dev] cffi in stdlib
Hi Neil, On Thu, Feb 28, 2013 at 12:34 AM, Neil Hodgson nyamaton...@me.com wrote: Wouldn't it be better to understand the SAL annotations like _In_opt so that spurious NULLs (for example) produce a good exception from cffi instead of failing inside the system call? Maybe. Feel like adding an issue to https://bitbucket.org/cffi/cffi/issues, with references? This looks like a Windows-specific extension, which means that I don't automatically know about it. A bientôt, Armin. ___ 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] cffi in stdlib
On 27 February 2013 23:18, Armin Rigo ar...@tunes.org wrote: from cffi import FFI ffi = FFI() ffi.cdef( int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType); ) lib = ffi.dlopen(USER32.DLL) lib.MessageBox(ffi.NULL, Hello, world!, Title, 0) Yeah, that's loads better than 0.5. Presumably ffi.NULL isn't needed and I can use 0? (After all, 0 and NULL are equivalent in C, so that's not a correctness issue). The auto-conversion of strings is a huge improvement. That's a slightly unfair example, because in this case it happens to work with ctypes without specifying the argtypes and the restype. I would argue that this feature of ctypes is not a good thing: it's mostly the same as saying you only need to declare argtypes and restype if you get nonsense results or segfaults. That's a bit unfair. I'd say you only need to declare argtypes if you're dealing with things more complex than integers, strings and null pointers. Which means you're fine for a huge proportion of the Windows API. On the other hand, going to the API level and being able to use all the Windows constants without having to look them up (their values aren't documented, so googling doesn't help :-() is a huge plus. Paul. ___ 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] cffi in stdlib
Hi Paul, On Thu, Feb 28, 2013 at 9:27 AM, Paul Moore p.f.mo...@gmail.com wrote: Presumably ffi.NULL isn't needed and I can use 0? (After all, 0 and NULL are equivalent in C, so that's not a correctness issue). Indeed. I created https://bitbucket.org/cffi/cffi/issue/61/convert-0-to-a-null-pointer. In C, NULL is typically #define NULL (void *)0, not just 0, which means that there are not 100% equivalent. But it's true that in C you can pass the constant 0 to mean a NULL pointer argument. The fact that it's not working this way in CFFI is definitely a bug. That's a slightly unfair example, because in this case it happens to work with ctypes without specifying the argtypes and the restype. I would argue that this feature of ctypes is not a good thing: it's mostly the same as saying you only need to declare argtypes and restype if you get nonsense results or segfaults. That's a bit unfair. I'd say you only need to declare argtypes if you're dealing with things more complex than integers, strings and null pointers. Which means you're fine for a huge proportion of the Windows API. Yes, you're right, and the 32-bit Windows platform is still important. However, it only works on 32-bit. On typical 64-bit Posix environments, if you don't declare argtypes/restype, you usually end up very quickly with confusion between int and long. And I think that even on 64-bit Windows, passing 0 as a NULL pointer is buggy, because it will pass a 32-bit 0. (It may be that it doesn't actually make a difference and works anyway, but I'm not sure.) Similarly, a function that returns a pointer (e.g. a handle on Windows) will not work without an explicit restype on any 64-bit platform I know of. Explicit is better than implicit... A bientôt, Armin. ___ 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] cffi in stdlib
On Thu, Feb 28, 2013 at 10:27 AM, Paul Moore p.f.mo...@gmail.com wrote: On 27 February 2013 23:18, Armin Rigo ar...@tunes.org wrote: from cffi import FFI ffi = FFI() ffi.cdef( int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType); ) lib = ffi.dlopen(USER32.DLL) lib.MessageBox(ffi.NULL, Hello, world!, Title, 0) Yeah, that's loads better than 0.5. Presumably ffi.NULL isn't needed and I can use 0? (After all, 0 and NULL are equivalent in C, so that's not a correctness issue). The auto-conversion of strings is a huge improvement. That's a slightly unfair example, because in this case it happens to work with ctypes without specifying the argtypes and the restype. I would argue that this feature of ctypes is not a good thing: it's mostly the same as saying you only need to declare argtypes and restype if you get nonsense results or segfaults. That's a bit unfair. I'd say you only need to declare argtypes if you're dealing with things more complex than integers, strings and null pointers. Which means you're fine for a huge proportion of the Windows API. No, if the int is of the wrong size or you pass int instead of float (but you meant float) you get nonsense or segfaults. ___ 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] cffi in stdlib
On 28 February 2013 09:06, Armin Rigo ar...@tunes.org wrote: And I think that even on 64-bit Windows, passing 0 as a NULL pointer is buggy, because it will pass a 32-bit 0. (It may be that it doesn't actually make a difference and works anyway, but I'm not sure.) Similarly, a function that returns a pointer (e.g. a handle on Windows) will not work without an explicit restype on any 64-bit platform I know of. Explicit is better than implicit... Ha, interesting. My test case was run on 64-bit Windows with 64-bit Python, and worked fine. But you're right, explicit is better, and I may have been luckier than I realised. And anyway my original point about whether cffi was as concise as ctypes for simple ABI-level Windows calls has been answered - yes it is, at least the next version will be. Thanks, Paul. ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Yes, avoiding that kind of thing is a key motivation for sys.implementation. Any proposal for is_jython blocks should instead be reformulated as a proposal for new sys.implementation attributes. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] cffi in stdlib
Le Thu, 28 Feb 2013 10:57:50 +1300, Greg Ewing greg.ew...@canterbury.ac.nz a écrit : Antoine Pitrou wrote: We have to find sufficiently silly species of snakes, though. Glancing through http://en.wikipedia.org/wiki/List_of_snakes, we have: Wart snakes Java wart snakes Pipe snakes Stiletto snakes Rubber boas Dog-faced water snakes Shovel-nosed snakes I'm looking forward to our shovel-nosed release plugging the XML security holes, then. Regards Antoine. ___ 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] cffi in stdlib
Le Thu, 28 Feb 2013 10:06:00 +0100, Armin Rigo ar...@tunes.org a écrit : Yes, you're right, and the 32-bit Windows platform is still important. However, it only works on 32-bit. On typical 64-bit Posix environments, if you don't declare argtypes/restype, you usually end up very quickly with confusion between int and long. And I think that even on 64-bit Windows, passing 0 as a NULL pointer is buggy, because it will pass a 32-bit 0. (It may be that it doesn't actually make a difference and works anyway, but I'm not sure.) Similarly, a function that returns a pointer (e.g. a handle on Windows) will not work without an explicit restype on any 64-bit platform I know of. Indeed, argument width is quite important :-) Also, on 64-bit Windows, long is 32-bit while size_t and pointers are 64-bit. Regards Antoine. ___ 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 Language Summit at PyCon: Agenda
Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work anymore? Regards Antoine. ___ 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] cffi in stdlib
Armin Rigo: Maybe. Feel like adding an issue to https://bitbucket.org/cffi/cffi/issues, with references? OK, issue #62 added. This looks like a Windows-specific extension, which means that I don't automatically know about it. While SAL is Windows-specific, gcc supports some similar attributes including nonnull and sentinel. Neil ___ 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] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
Having had some time to think about this problem space, here's my take on it:
===
The problem-space can be broken down into four layers:
1. the items
2. interaction between grouped items
3. the grouping itself
4. conversion from a class to a group
Here are *potential* characteristics at each layer:
items
-
* immutable
* unique
* proxies or otherwise implicitly exposes underlying value
* or only explicitly exposes value
* or *is* the value with extra attributes added on
* int-like
* immutable underlying values
* hashable
* repr shows group name, item name, and underlying value
* str shows just item name
* value-less
* a class that subclasses the group
items and item interaction
--
* equality comparible
* richly comparable
* comparison by identity only
* interaction restricted to within group
* flag-like (bitwise operations, etc.)
groups
--
* iterable
* sized
* ordered (sortable)
* inheritance to extend the group
* a class rather than an instance of an enum type
* query: name - value
* immutable
* immutable underlying collection of items
* allow aliases for actual items
* group itself is named
* has __qualname__
* repr shows items
* no duplicates
* a sequence without semantically meaningful values
* unserialize (value - item) using call syntax on group
conversion
--
* inherit a base enum type
* use a class decorator
* use a factory function, perhaps not even on a class (for more dynamic
enum creation)
* __getitem__() trick for defining value-less items
* auto-numbering
* explicit values
* implicit values using ...
* filter out private names
* use only upper-case names
There is a danger in trying to make an enum that is capable of doing
everything. People need a simple common ground. When an object is an
enum, a developer should be able to know immediately how to interact
with it and that interaction should have a small cross-section.
===
With that in mind and considering a lot of the discussion that has
gone on, here's an API that tries to find a middle ground:
items
NamedValue #Nick's recipe
NamedItem #an opaque named wrapper around a value
group # the enum to which the item belongs
value # the wrapped value
__qualname__ # group qualname + item name
__repr__ - class + qualname + value
__str__ - item name
__eq__ - NotImplemented
expose(ns) # export the value out to any namespace
OrderedItem(NamedItem) # a totally ordered item
__eq__ - other is self
__lt__ - ask self.group to decide
FlagItem(NamedItem) # a bitwise/set operation compatible item
__and__ - ask self.group to do it
...
FlagsItem(FlagItem) # the result of FlagItem bitwise operations
__repr__ - shows the the items or'ed together
items # the items that were joined together by the operation
IntItem(NamedItem) # for those that really need a named item to be a
little less opaque
__int__
__index__
__bool__
groups
Group
__name__
__qualname__
__items__ # the underlying collection of items (tuple or frozenset)
_ns # a GroupValues instance for the group
__repr__ - group name + items
__call__(value) - item # essentially the unserializer for an item
_expose(ns) # calls expose() on each item in the group
OrderedGroup # corresponds to OrderedItem
FlagGroup # corresponds to FlagItem
GroupValues # a Mapping proxy around a group's (name - value)
conversion
named_values_from_class() - {name: value} # simply extract the
values from the class
auto_int_from_class() # a classic enum
auto_bin_from_class() # similar but steps in powers of 2
as_enum(*, ordered=False, flagged=False, converter=..., strict=True,
**kwargs) # the main class decorator factory
Examples:
@as_enum()
class Spam:
A = ...
B = ...
C = ...
Spam.A._expose(globals())
@as_enum(converter=auto_bin_from_class, flagged=True)
class Ham:
A = 1
B = ...
C = ...
D = 32
Ham.A == 1 # False
Ham.B | Ham.C # a FlagsItem containing the two
iter(Ham) # TypeError
iter(Ham.__items__) # the items
iter(Ham._ns) # the names
iter(Ham._ns.values()) # the values
Key points:
* uses a class decorator rather than inheritance to convert a class into an enum
* the objects make use of __qualname__ as much as is reasonable
* the various Item classes are meant to be compatible (e.g. multiple
inheritance)
* groups and items are immutable
* if order matters, using a class decorator requires that classes use
OrderedDict by default for their namespace,
this is a feasible change once we have an OrderedDict written in C
(issue #16991)
* value-less NamedItems are totally valid and the use of ... in
converters would support their creation
* the Group API is very simple (what you are using over and over)
* the definition/conversion API is a little thicker with the basic
case simplified
* NamedItems are simply opaque wrappers (with the mild exception of IntItem)
* Nick's
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 28/02/13 07:20, anatoly techtonik wrote: * as an exercise - try to build a scroller for a running Python script * it is impossible for Python 2 and probably for Python 3 as well What do you mean by a scroller? [...] and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license If you are correct, that may be a real issue that needs to be resolved. If this issue has been discussed before, can you point me to a previous discussion please? -- Steven ___ 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 Language Summit at PyCon: Agenda
On Feb 27, 2013, at 3:20 PM, anatoly techtonik techto...@gmail.com wrote: * security by obscurity in legal position of PSF towards contributors https://code.google.com/legal/individual-cla-v1.0.html vs http://www.python.org/psf/contrib/contrib-form/ + http://www.samurajdata.se/opensource/mirror/licenses/afl-2.1.php or http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license I'm not even touching your security through obscurity trollbait, but I'd like to know how the PSF / Python core is non compliant with clause 4, and the legal counsel you spoke to to confirm this. Jesse___ 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 Language Summit at PyCon: Agenda
On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. Michael Georg ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] High volumes and off topic discussions
Hi I know this is a hard topic, but python-dev is already incredibly high-volume and dragging discussion off-topic is making following important stuff (while ignoring unimportant stuff) very hard. For example in a recent topic cffi in stdlib I find a mail that says we have to find a sufficiently silly species of snake. It's even funny, but it definitely makes it very hard to follow for those of us who don't read python-dev 24/7. Would it be reasonable for python-dev to generally try to stay on topic (for example if the thread is called silly species of snakes, I absolutely don't mind people posting there whatever they feel like as long as I'm not expected to read every single message). Cheers, fijal ___ 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 Language Summit at PyCon: Agenda
On 27 Feb 2013, at 18:50, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 27 Feb 2013 16:51:16 + Michael Foord mich...@voidspace.org.uk wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. Perhaps someone wants to discuss http://www.python.org/dev/peps/pep-0428/, but I won't be there and the PEP isn't terribly up-to-date either :-) If you can find someone familiar with pathlib to champion the discussion it is more likely to happen and be productive... Getting the PEP up to date before the summit will also help. (I very much like the *idea* of pathlib and the bits I've seen / read through - but I haven't used it in anger yet so I don't feel qualified to champion it myself.) Michael Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
Jesse Noller jnol...@gmail.com wrote: http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/ licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license I'm not even touching your security through obscurity trollbait, but I'd like to know how the PSF / Python core is non compliant with clause 4, and the legal counsel you spoke to to confirm this. Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah ___ 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 Language Summit at PyCon: Agenda
On 27 Feb 2013, at 19:01, fwierzbi...@gmail.com wrote: On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord mich...@voidspace.org.uk wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to discuss merging Jython's standard Lib (the *.py files). We have in the past had agreement that this would be a good idea - I just want to bring it up since I think this is probably the year that I'm actually going to do it. Added to the agenda. Michael -Frank ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 28 Feb 2013, at 03:42, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 04:51 PM, Michael Foord wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to have some discussions around promotion of Python 3, how we can accelerate its adoption, availability of supporting packages, what critical projects are still missing, etc. Added to the agenda. Michael -Barry ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 6:42 AM, Stefan Krah ste...@bytereef.org wrote: Jesse Noller jnol...@gmail.com wrote: http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/ licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license I'm not even touching your security through obscurity trollbait, but I'd like to know how the PSF / Python core is non compliant with clause 4, and the legal counsel you spoke to to confirm this. Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org ___ 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/jnoller%40gmail.com ___ 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 Language Summit at PyCon: Agenda
Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. ___ 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/jnoller%40gmail.com ___ 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 Language Summit at PyCon: Agenda
Le Thu, 28 Feb 2013 06:57:36 -0500, Jesse Noller jnol...@gmail.com a écrit : On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. Really? I didn't know lawyers flocked at the PSF. It also doesn't provide any public feedback for said resolution, meaning it doesn't help alleviate any future discussions about legal issues. Regards Antoine. ___ 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 Language Summit at PyCon: Agenda
Jesse Noller jnol...@gmail.com wrote: We have one: p...@python.org That's not exactly a public mailing-list. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. If the list isn't publicly archived, the same questions will arise over and over again (probably on python-dev). Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? Stefan Krah ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 7:23 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:57:36 -0500, Jesse Noller jnol...@gmail.com a écrit : On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. Really? I didn't know lawyers flocked at the PSF. It also doesn't provide any public feedback for said resolution, meaning it doesn't help alleviate any future discussions about legal issues. Regards Antoine. Yes sir. Ill have a new mailing list made today. I will note on the list page that is is strictly unofficial and all legal / lawyer type things must be sent to p...@python.org for official decisions or legal counsel. ___ 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/jnoller%40gmail.com ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 7:31 AM, Jesse Noller jnol...@gmail.com wrote: On Feb 28, 2013, at 7:23 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:57:36 -0500, Jesse Noller jnol...@gmail.com a écrit : On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. Really? I didn't know lawyers flocked at the PSF. It also doesn't provide any public feedback for said resolution, meaning it doesn't help alleviate any future discussions about legal issues. Regards Antoine. Yes sir. Ill have a new mailing list made today. I will note on the list page that is is strictly unofficial and all legal / lawyer type things must be sent to p...@python.org for official decisions or legal counsel. Spent a minute driving to request the new list. Will notify when it's up ___ 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/jnoller%40gmail.com ___ 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 Language Summit at PyCon: Agenda
Stefan Krah writes: Why would [the PSF list] help to resolve such an issue (if it is an issue at all!) Precisely. If there *is* a compliance problem, there's nothing to be done before talking to the lawyers. Although license *choice* is primarily a political issue, *compliance* is technical. ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 8:03 AM, Stephen J. Turnbull step...@xemacs.org wrote: Stefan Krah writes: Why would [the PSF list] help to resolve such an issue (if it is an issue at all!) Precisely. If there *is* a compliance problem, there's nothing to be done before talking to the lawyers. Although license *choice* is primarily a political issue, *compliance* is technical. And the board is legally bound to ensure compliance. I know, I've gotten the email requests clarifying copyright assignments. That being said, I requested a mailing list where this can all be hotly debated and will let everyone know when the playground is open. ___ 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/jnoller%40gmail.com ___ 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 Language Summit at PyCon: Agenda
On 28/02/13 23:26, Stefan Krah wrote: Jesse Noller jnol...@gmail.com wrote: We have one: p...@python.org That's not exactly a public mailing-list. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. If the list isn't publicly archived, the same questions will arise over and over again (probably on python-dev). Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? Because we can ask somebody on the PSF to commit to replying here with the resolution: - No, we have legal advice that we are not violating the Apache license, and here's why... - Yes, we are violating the license, and this is what we are going to do to fix it... The question of whether or not the PSF is violating the Apache license in some way is not one that is helped by having arbitrary people give their uninformed opinions. I sympathize with curious people wanting to see what's going on, but really, this is not a question to be debated and argued by amateurs and non-lawyers. The PSF has a tame lawyer for exactly these sorts of matters, and we should let him do his job. In any case, until Anatoly replies with details, this counts as nothing more than an unsubstantiated, vague accusation. Over to you Anatoly... -- Steven ___ 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 Language Summit at PyCon: Agenda
Le Fri, 01 Mar 2013 00:21:48 +1100, Steven D'Aprano st...@pearwood.info a écrit : The question of whether or not the PSF is violating the Apache license in some way is not one that is helped by having arbitrary people give their uninformed opinions. I sympathize with curious people wanting to see what's going on, but really, this is not a question to be debated and argued by amateurs and non-lawyers. Similarly, programming questions are not to be debated by amateurs and non-programmers. We should just close python-dev. Regards Antoine. ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.ukwrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. ___ 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 Language Summit at PyCon: Agenda
2013/2/28 Brett Cannon br...@python.org: On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. How close are they to being applied? -- Regards, Benjamin ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 8:53 AM, Benjamin Peterson benja...@python.orgwrote: 2013/2/28 Brett Cannon br...@python.org: On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. How close are they to being applied? I have no idea. Ask Christian. =) I can just answer what the attacks are and what had to change to protect against them. ___ 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] High volumes and off topic discussions
Le Thu, 28 Feb 2013 13:36:10 +0200, Maciej Fijalkowski fij...@gmail.com a écrit : Hi I know this is a hard topic, but python-dev is already incredibly high-volume and dragging discussion off-topic is making following important stuff (while ignoring unimportant stuff) very hard. For example in a recent topic cffi in stdlib I find a mail that says we have to find a sufficiently silly species of snake. It's even funny, but it definitely makes it very hard to follow for those of us who don't read python-dev 24/7. Would it be reasonable for python-dev to generally try to stay on topic (for example if the thread is called silly species of snakes, I absolutely don't mind people posting there whatever they feel like as long as I'm not expected to read every single message). I'm afraid you're trying to devise derogatory distinctions regarding drifting discussions. Seriously, yes, I approve of changing the subject line, although I forgot to do it this time. For the record, you can also read the list through a NNTP gateway using Gmane, it can make things easier. Regards Antoine. ___ 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] New mailing list: Python-legal-sig
See: http://mail.python.org/mailman/listinfo/python-legal-sig Open archives. As the header says this is for the discussion of CLA/other issues. If specific legal questions or alterations to Python/the PSF trademarks, CLA/etc are requested those *must* be sent to p...@python.org for board oversight and approval. This is an open discussion list, and is not official legal stance of the foundation, trademarks, etc. jesse ___ 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 Language Summit at PyCon: Agenda
On Thursday, February 28, 2013 at 7:26 AM, Stefan Krah wrote: Jesse Noller jnol...@gmail.com (mailto:jnol...@gmail.com) wrote: We have one: p...@python.org (mailto:p...@python.org) That's not exactly a public mailing-list. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. If the list isn't publicly archived, the same questions will arise over and over again (probably on python-dev). Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? See: http://mail.python.org/pipermail/python-dev/2013-February/124463.html ___ 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 Language Summit at PyCon: Agenda
Steven D'Aprano st...@pearwood.info wrote: The question of whether or not the PSF is violating the Apache license in some way is not one that is helped by having arbitrary people give their uninformed opinions. No one will be preventing lawyers from giving their opinions on python-legal. In fact, at least one patent attorney *is* posting on debian-legal. Jesse is right: the list may turn into a playground. In that case, at least the traffic is not on python-dev. Stefan Krah ___ 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 Language Summit at PyCon: Agenda
Jesse Noller jnol...@gmail.com wrote: Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? See: http://mail.python.org/pipermail/python-dev/2013-February/124463.html That was quick. Thanks! Stefan Krah ___ 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 Language Summit at PyCon: Agenda
On Thursday, February 28, 2013 at 9:49 AM, Stefan Krah wrote: Jesse Noller jnol...@gmail.com (mailto:jnol...@gmail.com) wrote: Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? See: http://mail.python.org/pipermail/python-dev/2013-February/124463.html That was quick. Thanks! Stefan Krah It only takes a minute or two to do something good. Now how about dem XML vulnerabilities? ;) ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 7:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: I am suggesting that we push forward on the shared library approach to the files in the Lib/* directory, so that would certainly include IronPython and PyPy as well I hope. +1 The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Sorry I meant is_jython as a sort of shorthand for a case by case check. It would be cool if we had a nice set of checks somewhere like is_refcounted, etc. Would the sys.implementation area be a good place for such things? On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) -Frank ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:15 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Yes, avoiding that kind of thing is a key motivation for sys.implementation. Any proposal for is_jython blocks should instead be reformulated as a proposal for new sys.implementation attributes. Ah nice - the merging effort should definitely cause some careful consideration of these. Maybe I'll start a discussion about a garbage collection type for sys.implementation. Some way to ask gc != refcounted would catch some of these. -Frank ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work anymore? That is definitely something to think about. Maybe when this becomes a serious effort and not just talk I can help get a Jython buildbot going. -Frank ___ 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] High volumes and off topic discussions
On Thu, Feb 28, 2013 at 4:03 PM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 13:36:10 +0200, Maciej Fijalkowski fij...@gmail.com a écrit : Hi I know this is a hard topic, but python-dev is already incredibly high-volume and dragging discussion off-topic is making following important stuff (while ignoring unimportant stuff) very hard. For example in a recent topic cffi in stdlib I find a mail that says we have to find a sufficiently silly species of snake. It's even funny, but it definitely makes it very hard to follow for those of us who don't read python-dev 24/7. Would it be reasonable for python-dev to generally try to stay on topic (for example if the thread is called silly species of snakes, I absolutely don't mind people posting there whatever they feel like as long as I'm not expected to read every single message). I'm afraid you're trying to devise derogatory distinctions regarding drifting discussions. Seriously, yes, I approve of changing the subject line, although I forgot to do it this time. For the record, you can also read the list through a NNTP gateway using Gmane, it can make things easier. How does that help with knowing what mails to read what mails not to read? the agenda thread is a great example - I care about the agenda, because I'm even mentioned there, but I don't care about the legal mailing list that occupies 2/3 of the thread. People who like to care about legal stuff would be baffled that noone told them, because it was buried inside a thread about a conference they might not go to etc. Anyway, I'm not even a regular here so do what works for you. Regards Antoine. ___ 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/fijall%40gmail.com ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work anymore? Agreed on those problems. Would it be possible to use a design pattern in these cases so the Jython-only code wouldn't need to be part of the CPython repo? A naive example would be refactoring zlib to allow subclassing in the way that Jython needs, and then Jython could subclass in its own repo. CPython could have tests to check the subclass contract that Jython needs. --Chris ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, Feb 28, 2013 at 11:24 AM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work anymore? Agreed on those problems. Would it be possible to use a design pattern in these cases so the Jython-only code wouldn't need to be part of the CPython repo? A naive example would be refactoring zlib to allow subclassing in the way that Jython needs, and then Jython could subclass in its own repo. CPython could have tests to check the subclass contract that Jython needs. What about a plat-java section to parallel plat-aix4, plat-darwin, etc? The analogy being that the Java platform is somewhat analogous to being it's own os? And these areas are not active when on other operating systems... -Frank ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, Feb 28, 2013 at 11:46 AM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: Agreed on those problems. Would it be possible to use a design pattern in these cases so the Jython-only code wouldn't need to be part of the CPython repo? A naive example would be refactoring zlib to allow subclassing in the way that Jython needs, and then Jython could subclass in its own repo. CPython could have tests to check the subclass contract that Jython needs. What about a plat-java section to parallel plat-aix4, plat-darwin, etc? The analogy being that the Java platform is somewhat analogous to being it's own os? And these areas are not active when on other operating systems... Oh yeah and this does not preclude the zlib refactoring, and again for the record once this gets serious I'd want to help in bringing up a Jython buildbot to track breakage. -Frank ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, 28 Feb 2013 11:46:04 -0800 fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Thu, Feb 28, 2013 at 11:24 AM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work anymore? Agreed on those problems. Would it be possible to use a design pattern in these cases so the Jython-only code wouldn't need to be part of the CPython repo? A naive example would be refactoring zlib to allow subclassing in the way that Jython needs, and then Jython could subclass in its own repo. CPython could have tests to check the subclass contract that Jython needs. What about a plat-java section to parallel plat-aix4, plat-darwin, etc? The analogy being that the Java platform is somewhat analogous to being it's own os? And these areas are not active when on other operating systems... IMHO, we should remove the plat-* directories, they are completely unmaintained, undocumented, and serve no useful purpose. Regards Antoine. ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, Feb 28, 2013 at 12:00 PM, Antoine Pitrou solip...@pitrou.net wrote: IMHO, we should remove the plat-* directories, they are completely unmaintained, undocumented, and serve no useful purpose. Oh I didn't know that - so definitely adding to that is right out :) Really for cases like Jython's zlib.py (no useful code for CPython) I don't have any trouble keeping them entirely in Jython. It just would have been fun to delete our Lib/ :) It would be nice in this particular case if there was a zlib.py that imported _zlib -- then it would be easy to shim in Jython's version, whether it is written in a .py file or in Java. -Frank ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, Feb 28, 2013 at 3:17 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Thu, Feb 28, 2013 at 12:00 PM, Antoine Pitrou solip...@pitrou.net wrote: IMHO, we should remove the plat-* directories, they are completely unmaintained, undocumented, and serve no useful purpose. Oh I didn't know that - so definitely adding to that is right out :) Really for cases like Jython's zlib.py (no useful code for CPython) I don't have any trouble keeping them entirely in Jython. It just would have been fun to delete our Lib/ :) It would be nice in this particular case if there was a zlib.py that imported _zlib -- then it would be easy to shim in Jython's version, whether it is written in a .py file or in Java. That should be fine as that is what we already do for accelerator modules anyway. If you want to work towards having an equivalent of CPython's Modules/ directory so you can ditch your custom Lib/ modules by treating your specific code as accelerators I think we can move towards that solution. ___ 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] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]
On Thu, Feb 28, 2013 at 1:35 PM, Brett Cannon br...@python.org wrote: That should be fine as that is what we already do for accelerator modules anyway. If you want to work towards having an equivalent of CPython's Modules/ directory so you can ditch your custom Lib/ modules by treating your specific code as accelerators I think we can move towards that solution. +1 -eric ___ 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] Announcing PEP 436: The Argument Clinic DSL
On 02/26/2013 06:30 PM, Terry Reedy wrote: On 2/26/2013 1:47 PM, Larry Hastings wrote: I think positional-only functions should be discouraged, but we don't If I were writing something like Clinic, I would be tempted to not have that option. But I was actually thinking about something in the positional-only writeup that mentioned the possibility of adding something to the positional-only option. Clinic needs to be usable for every builtin in order to be a credible solution. And the positional-only approach to parsing is sufficiently different from the positional-and-keywords approach that I couldn't sweep the conceptual difference under the rug--I had to explicitly support weird stuff like optional positional arguments on the /left/. So I really don't have a choice. All we can do is say please don't use this for new code. As I understand it, C module files are structured something like the following, which is 'unusual' for a python file. def meth1_impl(... def meth2_impl(... class C: meth1 = meth1_impl meth2 = meth2_impl At the moment Clinic is agnostic about where in Python the callable lives. The module name in the DSL is really just used in documentation and to construct the name of the static functions. So if you specify a class name as your module name it'll work fine and look correct. However, maybe we need to think about this a little more when it comes time to add Signature metadata. //arry/ ___ 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 Language Summit at PyCon: Agenda
On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) Since the time I suggested we add packaging to the agenda, Nick has set up a separate summit meeting for Friday evening. I don't know if it makes sense to leave this on the agenda for Wednesday or not. Nick, what do you think? Doug * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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/doug.hellmann%40gmail.com ___ 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
