On Sun, 17 Feb 2013 14:00:24 +1100, Neil Hodgson wrote:
> Nick Coghlan:
>
> > - no need for extensive cross-OS testing prior to commit, that's a key
> > part of the role of the buildbots
>
>Are the buildbots able to test UI features like menu selections?
Not to mention that the test suite i
On Sat, Feb 16, 2013 at 2:06 PM, Daniel Holth wrote:
> This is the improved compatibility tags PEP 425, specifying how part of the
> Wheel PEP 427 filenames work. Last time we discussed whether replacing .
> with _ was ugly but I concluded it was harmless.
Daniel has updated the example and FAQ a
On Sun, Feb 17, 2013 at 1:36 PM, Eric Snow wrote:
> (See http://bugs.python.org/issue16251)
>
> The pickle module looks up special methods on instances rather than
> using the behavior described in the language reference (or even just
> looking them up on the class). This means that custom
> __ge
(See http://bugs.python.org/issue16251)
The pickle module looks up special methods on instances rather than
using the behavior described in the language reference (or even just
looking them up on the class). This means that custom
__getattribute__() and __getattr__() implementations may get trigg
Nick Coghlan:
> - no need for extensive cross-OS testing prior to commit, that's a key
> part of the role of the buildbots
Are the buildbots able to test UI features like menu selections?
Neil
___
Python-Dev mailing list
Python-Dev@python.org
ht
On Sun, Feb 17, 2013 at 10:45 AM, Todd Rovito wrote:
> On Sat, Nov 3, 2012 at 5:28 AM, Nick Coghlan wrote:
>> On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy wrote:
>>> [snip reasons]
>>> OK, I am convinced an info PEP would be a good idea.
>>
>> Unless anyone objects, I'm happy to be BDFL-delegate
On Sat, Feb 16, 2013 at 5:02 PM, Eric Snow wrote:
> On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou wrote:
>> I think you should test with all pickle protocols.
>
> I'll do that.
Out of curiousity, how critical is it to support protocols 0 and 1?
I've made sure SimpleNamespace does, but it made
On Sat, Nov 3, 2012 at 5:28 AM, Nick Coghlan wrote:
> On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy wrote:
>> [snip reasons]
>> OK, I am convinced an info PEP would be a good idea.
>
> Unless anyone objects, I'm happy to be BDFL-delegate for such a PEP. I
> mainly want to ensure we clearly fence of
On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou wrote:
> I think you should test with all pickle protocols.
I'll do that.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
Hello,
On Sun, 17 Feb 2013 00:42:26 +0100 (CET)
eric.snow wrote:
>
> +def test_pickle(self):
> +ns = types.SimpleNamespace(breakfast="spam", lunch="spam")
> +
> +ns_pickled = pickle.dumps(ns)
> +ns_roundtrip = pickle.loads(ns_pickled)
> +
> +self.assertEqual
On Sat, 16 Feb 2013 21:27:28 +1000
Nick Coghlan wrote:
> On Sat, Feb 16, 2013 at 9:17 PM, Nick Coghlan wrote:
> > Since Antoine and Stephen have pointed out my only non-cosmetic
> > concern was an error on my part, I am accepting the PEP. I'll update
> > the peps repo (including the cosmetic fix
Yury V. Zaytsev, 08.01.2013 10:28:
> Moreover, these days there is a clear trend towards OpenMP, so it has
> become even harder to pressure the manufacturers to fix threads, because
> they have 101 argument why you should port your code to OpenMP instead.
I can't see OpenMP being an *alternative*
Stefan Behnel wrote:
> > you'd just pass in this string:
> >
> >(arg1 : int, arg2 : float, arg3 : ExtType, *, arg4=None) -> ExtType2
I've mentioned this proposal in http://bugs.python.org/issue16612 , but
it wasn't sufficient for the task.
Stefan Krah
___
On Sat, Feb 16, 2013 at 9:17 PM, Nick Coghlan wrote:
> Since Antoine and Stephen have pointed out my only non-cosmetic
> concern was an error on my part, I am accepting the PEP. I'll update
> the peps repo (including the cosmetic fixes) in a moment.
And done: http://hg.python.org/peps/rev/d272d7a
Since Antoine and Stephen have pointed out my only non-cosmetic
concern was an error on my part, I am accepting the PEP. I'll update
the peps repo (including the cosmetic fixes) in a moment.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Nick Coghlan writes:
> For compatibility with file encoding declarations, I believe this
> needs to be relaxed to starting with '#!python' in the source file
> encoding, rather than strictly b'#!python' (which will only be the
> case for ASCII compatible encodings).
In any PEP-263-compatible
On Sat, Feb 16, 2013 at 8:12 PM, Antoine Pitrou wrote:
> On Sat, 16 Feb 2013 19:18:22 +1000
> Nick Coghlan wrote:
> I may be wrong, but I am not aware that Python is able to read encoding
> declarations in a non-ASCII compatible encoding :-)
>
> Also, given the shebang line is for use by the OS,
On Sat, 16 Feb 2013 11:12:49 +0100
Antoine Pitrou wrote:
> On Sat, 16 Feb 2013 19:18:22 +1000
> Nick Coghlan wrote:
> > On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth wrote:
> > > #. Python scripts must appear in ``scripts`` and begin with exactly
> > >``b'#!python'`` in order to enjoy scrip
On Sat, 16 Feb 2013 19:18:22 +1000
Nick Coghlan wrote:
> On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth wrote:
> > #. Python scripts must appear in ``scripts`` and begin with exactly
> >``b'#!python'`` in order to enjoy script wrapper generation and
> >``#!python`` rewriting at install tim
On Sat, Feb 16, 2013 at 2:06 PM, Daniel Holth wrote:
> This is the improved compatibility tags PEP 425, specifying how part of the
> Wheel PEP 427 filenames work. Last time we discussed whether replacing .
> with _ was ugly but I concluded it was harmless.
>
> Submitted for your consideration,
>
>
Yury V. Zaytsev wrote:
> On Mon, 2012-05-07 at 21:49 +0200, Antoine Pitrou wrote:
> >
> > I guess a long time ago, threading support in operating systems wasn't
> > very widespread, but these days all our supported platforms have it.
> > Is it still useful for production purposes to configure
> >
On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth wrote:
> #. Python scripts must appear in ``scripts`` and begin with exactly
>``b'#!python'`` in order to enjoy script wrapper generation and
>``#!python`` rewriting at install time. They may have any or no
>extension.
For compatibility w
On Sat, Feb 16, 2013 at 10:03 AM, Stefan Behnel wrote:
> Nick Coghlan, 16.02.2013 08:49:
>> Yes, the PyPy team and scientific users of Python have a long history
>> of talking past each other (and abusing each other for the mutual lack
>> of understanding). However, that's no excuse for deliberate
Nick Coghlan, 16.02.2013 08:49:
> Yes, the PyPy team and scientific users of Python have a long history
> of talking past each other (and abusing each other for the mutual lack
> of understanding). However, that's no excuse for deliberately ignoring
> the advantages JIT compilation can bring
No-on
24 matches
Mail list logo
