On Feb 16, 2012, at 09:54 PM, Nick Coghlan wrote:
>It turns out I'd forgotten what was in the PEP - the Notes section
>already contained a lot of suggestions along those lines. I changed
>the title of the section to "Migration Notes", but tried to make it
>clear that those *aren't* consensus recom
I've just committed a back port of issue 13703, the hash randomization patch,
to the Python 2.6 branch. I have left the forward porting of this to Python
2.7 to Benjamin.
test_json will fail with randomization enabled since there is a sort order
dependency in the __init__.py doctest. I'm not goi
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
>2012/2/21 Antoine Pitrou :
>>
>> Hello,
>>
>> Shouldn't it be enabled by default in 3.3?
Yes.
>Should you be able to disable it?
No, but you should be able to provide a seed.
-Barry
___
Python-D
On Feb 21, 2012, at 09:58 PM, Xavier Morel wrote:
>On 2012-02-21, at 21:24 , Brett Cannon wrote:
>> On Tue, Feb 21, 2012 at 15:05, Barry Warsaw wrote:
>>
>>> On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
>>>
>>>> 2012/2/21 Antoine Pitrou :
On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote:
>Brett Cannon writes:
>
> > I think that's inviting trouble if you can provide the seed. It leads to a
> > false sense of security
>
>I thought the point of providing the seed was for reproducability of
>tests and the like?
>
>As for "false
Two more small details to address, and then I think we're ready to start
creating release candidates.
- sys.flags.hash_randomization
In the tracker issue, I had previously stated a preference that this flag
only reflect the state of the -R command line option, not the
$PYTHONHASHSEED en
On Feb 24, 2012, at 10:39 PM, Martin v. Löwis wrote:
>> It is a burden for some people to learn and remember the exact details
>> of both systems and exactly how they differ. Having both in the stdlib
>> hurts readability for such people. I would prefer that the stdlib only
>> used {} formatting o
On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:
>* Improve datetime.datetime objects so they support nanosecond resolution,
> in such a way that it's 100% painless to make them even more precise in
> the future.
+1
>* Add support to datetime objects that allows adding and subtracting int
This seems like too strong a statement:
"Python 2.6 and Python 2.7 support syntax features from Python 3 which for
the most part make a unified code base possible. Many thought that the
unicode_literals future import might make a common source possible, but it
turns out that it's d
On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote:
>It reduces the problem (compared to omitting the import and using a
>u() function), but it's still ugly and still involves the "action at a
>distance" of the unicode literals import.
Frankly, that doesn't bother me at all. I've been using the fu
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
>On Sat, Feb 25, 2012 at 22:13, Guido van Rossum wrote:
>
>> If this can encourage more projects to support Python 3 (even if it's
>> only 3.3 and later) and hence improve adoption of Python 3, I'm all
>> for it.
>>
>>
>+1 from me for the same rea
On Feb 27, 2012, at 11:40 AM, Éric Araujo wrote:
> They’re all implemented in packaging/distutils2. Sadly, all of them
>have rather serious issues, so I wanted to ask what the process should
>be to solve the problems and mark the PEPs final.
From a process point of view, I'd say you should fix
On Feb 27, 2012, at 12:34 PM, Giampaolo Rodolà wrote:
>Il 25 febbraio 2012 21:23, Armin Ronacher
>If the main point of this proposal is avoiding an explicit 2to3 run on
>account of 2to3 being too slow then I'm -1.
2to3's speed isn't the only problem with the tool, although it's a big one.
It also
On Feb 27, 2012, at 11:21 AM, Martin v. Löwis wrote:
>I find this rationale a bit sad: it's not that there is any (IMO) good
>technical reason for the feature - only that people "hate" the many
>available alternatives for some reason.
It makes me sad too, and as I've said, I personally have no pr
On Feb 27, 2012, at 03:39 PM, Chris McDonough wrote:
>Note that u'' literals are sort of the tip of the iceberg here;
>supporting them will obviously not make development under the subset an
>order of magnitude less sucky, just a tiny little bit less sucky. There
>are other extremely annoying thi
On Feb 27, 2012, at 09:43 PM, Vinay Sajip wrote:
>Well, according to the approach I described above, that one thing needs to be
>the present 3.x syntax - 'xxx' is text, b'xxx' is bytes, and f('xxx') is
>native string (or whatever name you want instead of f). With the
>unicode_literals import, that
On Feb 27, 2012, at 02:06 PM, Guido van Rossum wrote:
>Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's
>about as harmless as they come. Make it so.
I've learned that once a PEP is pronounced upon, it's usually to my personal
(if not all of our mutual :) benefit to stop
On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote:
>Indeed I have three other PEPs in the work. The reintroduction of
>"except (((ExceptionType),),)", the "<>" comparision operator and the
>removal of "nonlocal", the latter to make Python 2.x developers feel
>better about themselves. :-)
One of
On Feb 28, 2012, at 08:41 AM, R. David Murray wrote:
>Hmm. It seems to me that this argument implies that PEP 414 is just
>as likely to *slow down* adoption of Python3 as it is to speed it up,
>since if this issue is as big a barrier as indicated, many potential
>porters may choose to wait until
On Feb 28, 2012, at 10:49 PM, Nick Coghlan wrote:
>On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou wrote:
>> Again that's wrong. If you cleverly use 2to3 to port between branches,
>> patches only have to be written against the 2.x version.
>
>Apparently *you* know how to do that, but I don't. If
On Feb 28, 2012, at 10:23 AM, Brett Cannon wrote:
>Well, when the code is committed I will update the porting HOWTO and push
>the __future__ imports first since they cover more versions of Python (i.e.
>Python 3.2). But I will mention the options that skip the __future__
>imports for those that ch
On Feb 28, 2012, at 11:29 AM, Yury Selivanov wrote:
>Could you please remove from the PEP the following statement:
>
>"""As it stands, Python 3 is currently a bad choice for long-term
>investments, since the ecosystem is not yet properly developed, and
>libraries are still fighting with their AP
On Feb 28, 2012, at 10:59 AM, Jim J. Jewett wrote:
>For many people -- particularly those who haven't ported yet -- 3.x
>will mean 3.3+. There are some who will support 3.2 because it is a
>LTS release on some distribution, just as there were some who supported
>Python 1.5 (but not 1.6) long into
On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:
>> If there is already a FAQ entry feel free to point me to it, but I would
>> still be curious why, in this instance, practicality does not beat purity?
>
>Because it's practical not to break bugfix releases with new features.
And because no
On Feb 29, 2012, at 07:30 AM, Yury Selivanov wrote:
>"""As it stands, Python 3 is currently a bad choice for long-term
>investments, since the ecosystem is not yet properly developed, and
>libraries are still fighting with their API decisions for Python 3."""
>
>to:
>
>"""As it stands, when chos
On Mar 01, 2012, at 04:42 PM, Antoine Pitrou wrote:
>Well, to be honest, "making good progress" currently means "bored and
>not progressing at all" :-) But that's not due to the strategy I
>adopted, only to the sheer amount of small changes needed, and lack of
>immediate motivation to continue thi
On Mar 01, 2012, at 09:42 AM, Guido van Rossum wrote:
>I noticed there were some complaints about unnecessarily offensive
>language in PEP 414. Have those passages been edited to everyone's
>satisfaction?
Not yet, but I believe Nick volunteered to do a rewrite.
-Barry
__
Hopefully, I can say the following in a constructive way. I certainly don't
mean to attack anyone personally for their closely held beliefs, though I
might disagree with them. And you have the right to those beliefs and to
express them in a respectful and constructive manner on this mailing list,
On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote:
>Consider: an application that uses 8-bit strings everywhere and blows up on
>non-ASCII data in Python 2 has at least a fighting chance to run unmodified
>*and* handle Unicode properly on Python 3. Because unicode literals are gone,
>a Unicode-awar
On Mar 02, 2012, at 12:58 PM, Hynek Schlawack wrote:
>3.3 is the IMHO the first 3.x release that brings really cool stuff to the
>table and might be the tipping point for people to start embracing Python 3 –
>despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I
>hope for so
On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote:
>FWIW, I think this issue's webness may be overestimated. There happens to be
>lots and lots of existing UI code which contains complex interactions between
>unicode literals and nonliterals in web apps, but there's also likely lots of
>nonweb
On Mar 02, 2012, at 09:23 PM, Hynek Schlawack wrote:
>Just to be clear: I didn't say 3.2 is “bad” or “not fine”. It's just the fact
>that people need more than “fine” to feel urged to switch to Python 3. I
>sincerely hope 3.3 fulfills that and if PEP 414 even makes porting easier we
>might have a
On Mar 04, 2012, at 05:34 PM, Nick Coghlan wrote:
>My rewritten version of PEP 414 is now up
>(http://www.python.org/dev/peps/pep-0414/). It describes in detail a lot more
>of the historical background that was taken as read when Guido accepted the
>PEP.
Nick, really great job with your rewrite o
On Mar 12, 2012, at 07:33 PM, Brett Cannon wrote:
>It came up at the sprints about how to choose new PEP numbers. It was
>agreed that the newest, *lowest* number should be used (e.g. 418) and not
>the next highest number (e.g. 3156). I have already updated PEP 1 to
>reflect this.
+1
-Barry
_
On Mar 17, 2012, at 11:34 PM, barry.warsaw wrote:
>http://hg.python.org/cpython/rev/6144a0748a95
>changeset: 75809:6144a0748a95
>branch: 2.6
>parent: 75806:bd9e1a02e3e3
>user: Barry Warsaw
>date:Sat Mar 17 18:34:05 2012 -0400
>summary:
>
On Mar 18, 2012, at 12:03 AM, Georg Brandl wrote:
>I'm afraid it's the latter: tags are entries in .hgtags. So when you
>completely null-merge your 2.6 changes into 2.7, you are basically removing
>the tag from the 2.7 branch. And since to find tags, Mercurial looks in the
>.hgtags files of all a
On Mar 17, 2012, at 07:15 PM, Éric Araujo wrote:
>Note that duplicate entries in .hgtags (when a tag was redone) should
>not be “cleaned up”: the presence of the old changeset hash greatly
>helps conflict resolution. (If someone pulled the repo with the old tag
>and later pulls and updates, then
On Mar 19, 2012, at 05:25 PM, Tshepang Lekhonkhobe wrote:
>apology: I searched for a few minutes and could not find a code of
>conduct regarding HTML mail.
I'm not sure it's written down anywhere, but in general we strongly discourage
HTML email for the lists @python.org
>Can we have some guidel
On Apr 03, 2012, at 12:44 AM, Antoine Pitrou wrote:
>I don't think Barry still uses bzr, and who ever used git to manage their
>patches against the CPython repo?
I still use bzr, but not currently for Python development. I just use the
standard hg repo. I'd like to go back to it though once the
On Apr 14, 2012, at 03:32 PM, Guido van Rossum wrote:
>Funny, I was just thinking about having a simple standard API that
>will let you open files (and list directories) relative to a given
>module or package regardless of how the thing is loaded.
I tend to use the "basic resource access" API of
On Apr 15, 2012, at 02:12 PM, Glyph wrote:
>Twisted has such a thing, mostly written by me, called
>twisted.python.modules.
>
>Sorry if I'm repeating myself here, I know I've brought it up on this list
>before, but it seems germane to this thread. I'd be interested in getting
>feedback from the i
On Apr 15, 2012, at 01:13 PM, Raymond Hettinger wrote:
>We should publish some advice on creating content managers.
I agree, I'm just not sure PEP 8 is the right place for it.
PEP 8 seems like it is structured more as mechanical guidelines for the look
and feel of code, not so much for the seman
On Apr 16, 2012, at 07:44 PM, Antoine Pitrou wrote:
>Wouldn't it be better if Python could compile regardless of the
>presence of a hg repository?
If you want it in your $DISTRO, yes please!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http
On Apr 17, 2012, at 08:25 AM, R. David Murray wrote:
>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
>> On 16.4.2012 18:10, Nam Nguyen wrote:
>> > a_list[pos + 1 : -1]
>>
>> or other way around
>>
>> a_list[pos+1:-1]
>
>
>That's what I always use. No spaces inside the brackets for me :)
On Apr 18, 2012, at 09:26 PM, Guido van Rossum wrote:
>On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote:
>> On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote:
>>> (quoting GvR)
Let's change this to something more reasonable, e.g.
"""
If operators with different priori
On Apr 19, 2012, at 11:00 AM, Éric Araujo wrote:
>Hi,
>
>> +- If operators with different priorities are used, consider adding
>> + whitespace around the operators with the lowest priority(ies). This
>> + is very much to taste; however, never use more than one space, and
>> + always have the sa
On Apr 20, 2012, at 09:59 PM, Brett Cannon wrote:
>As I clean up Python/import.c and move much of its functionality into
>Lib/imp.py, I am about to run into some stuff that was not kept private to
>the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type
>which I would like to c
On Apr 25, 2012, at 12:44 PM, Stephen J. Turnbull wrote:
>Note that people who are really annoyed by the duplicates can set
>their Mailman accounts to no-dupes, and Mailman won't send the post to
>that person. (This has its disadvantages in principle -- no List-*
>headers and other list-specific
On Apr 25, 2012, at 01:58 PM, Chris Angelico wrote:
>I go the other way: hit Reply, and then replace the author's address
>with the list's. I'd much rather have a Reply List though.
>Unfortunately no decent webmail seems to have it, and I'm still
>looking for a decent non-web-mail client too.
It'
I want to take this opportunity to make folks aware of several Python 3
porting initiatives and resources.
In Ubuntu 12.10, we are going to be making a big push to target all the
applications and libraries on the desktop CDs to Python 3. While this is a
goal of Ubuntu, the intent really is to wor
On Apr 25, 2012, at 11:31 PM, Eric Snow wrote:
>The proposal of adding sys.implementation has come up a couple times
>over the last few years. [1][2] While the reaction has been
>overwhelmingly positive, nothing has come of it. I've created a
>tracker issue and a patch:
>
>http://bugs.python
On Apr 30, 2012, at 08:42 AM, Guido van Rossum wrote:
>IT would be good if the author of one of the pdb add-ons such as (I
>believe) pdb2 could comment on this bug.
Maybe we should take this opportunity (Python 3.3) to consider adopting one of
the pdb add-ons or borging the best of their bits int
On May 01, 2012, at 10:40 AM, R. David Murray wrote:
>I guess it's time to talk about my plans for this one :)
Thanks for the update RDM. I really wish I had more time to contribute to
email6, but I'd still really like to see this land in 3.3 if possible.
I suspect you're just not going to get
On May 01, 2012, at 11:30 PM, Nick Coghlan wrote:
>> * Breaking out standard library and docs in separate repos?
>
>Our current development infrastructure simply isn't set up to cope
>with this. With both 407 and 413 still open (and not likely to go
>anywhere any time soon), this simply isn't goin
On May 01, 2012, at 08:24 AM, Eric V. Smith wrote:
>Oops, I missed your reference to PEP 402 and PEP 420. Sorry about that.
>
>It is indeed 420 that would replace 402.
And the older PEP 382. Once 420 is accepted, we should simply reject 382 and
402. At that point, I'll update them to point to 4
On May 05, 2012, at 04:04 PM, Christian Heimes wrote:
>The fix needs the dpkg-architecture program. As Tshepang pointed out it
>may not be available on Edward's box. I always install build-essential
>on all development boxes as it includes GCC, make and dpkg-dev.
That's probably it. Certainly Py
Thanks for doing this update Nick. I have just a few comments.
On May 05, 2012, at 02:57 PM, nick.coghlan wrote:
>+Developers with commit privileges for the `PEP repository`_ may claim
>+PEP numbers directly by creating and committing a new PEP. When doing so,
>+the developer must handle the tas
On May 05, 2012, at 12:56 PM, Barry Warsaw wrote:
>before the final PEP can be approved. When an `PEP-Czar` header must be
>added to the PEP to record this delegation. The format of this header is
>the same as the `Author` header.
s/When an/A
On May 06, 2012, at 09:31 AM, Antoine Pitrou wrote:
>I have to ask - is email obfuscation still useful these days?
I think it's more important that Python developers (especially those
submitting or pronouncing on PEPs) can be contacted by other Python
developers. I *personally* don't care about
On May 06, 2012, at 03:08 PM, Nick Coghlan wrote:
>I'll see if I can figure out something - I may just put in text like
>"if you're at all unsure about what needs to be done, email the PEP
>editors anyway".
The diff looks good, thanks.
-Barry
___
Pytho
On May 07, 2012, at 04:42 PM, Edward C. Jones wrote:
>I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
>and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
>with python3.2 (and 2.6 and 2.7). I installed the Debian package
>python3-bs4 (BeautifulSou
On May 08, 2012, at 11:13 AM, Brett Cannon wrote:
>This really isn't the right mailing list to ask this kind of question (I
>know you got help last time with your Debian-specific problem, but that was
>because people got overly excited =). Python-dev is meant for discussing
>the development *of* P
On May 08, 2012, at 11:59 AM, Nick Coghlan wrote:
>No, the "mcl" in the call is just the designated metaclass - the
>*actual* metaclass of the resulting class definition may be something
>different. That's why this is a separate method from mcl.__new__.
I'm not completely sold on adding a class m
Hi Eric,
Great job on the latest PEP 421. I really like it. A few additional
comments/questions.
* sys.implementation.version
This is defined as the version of the implementation, while
sys.version_info is the version of the language. The semantics of
sys.version_info have been suff
On May 09, 2012, at 02:17 AM, Matthias Klose wrote:
>IMO, the correct fix would be not to hard-code the system include and library
>directories, but get them from gcc directly (if CC is gcc), and not relying on
>dpkg-architecture.
>
>$ gcc -v -E - [...]
>#include <...> search starts here:
> /usr/l
On May 09, 2012, at 05:20 PM, Nick Coghlan wrote:
>Ah, good point. In that case, consider me convinced: static method it
>is. It can join mro() as the second non-underscore method defined on
>type().
+1
If I may dip into the bikeshed paint once more. I think it would be useful to
establish a na
On May 08, 2012, at 09:03 PM, Eric Snow wrote:
>> This is defined as the version of the implementation, while
>> sys.version_info is the version of the language. The semantics of
>> sys.version_info have been sufficiently squishy in the past, as the XXX
>> implies. This PEP shouldn't try
On May 09, 2012, at 08:51 AM, Eric Snow wrote:
>The type for sys.implementation has slowly shifted from the original
>proposal. At this point it's settled into where I think it will stay,
>a custom type. I've covered the choice of type in the rationale
>section. However, there may be merit in n
On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>Sure, but couldn't we define this "empty" class in C code so that you can
>use the C API with it as well and just provide a C function to get a new
>instance?
+1
ISTM to be a companion to collections.namedtuple. IWBNI this new type was
also exp
On May 09, 2012, at 05:47 PM, Larry Hastings wrote:
>I like Alex Martelli's approach, which I recall was exactly this:
>
>class namespace:
> def __init__(**kwargs):
> self.__dict__ = kwargs
>
>
>That means all the initializers you pass in to the constructor get turned
>into
On May 09, 2012, at 07:44 PM, R. David Murray wrote:
>On Thu, 10 May 2012 08:14:55 +1000, Nick Coghlan wrote:
>> Given that the statement form is referred to as a "class definition", and
>> this is the dynamic equivalent, I'm inclined to go with "type.define()".
>> Dynamic type definition is more
On May 10, 2012, at 10:57 AM, Antoine Pitrou wrote:
>sys.implementation.metadata looks like a completely over-engineered
>concept. Please, let's just make sys.implementation a dict and stop
>bothering about ordering and iterability.
I guess the question is whether immutability is useful to preser
On May 12, 2012, at 10:04 PM, Nick Coghlan wrote:
>On Sat, May 12, 2012 at 12:40 PM, Eric Snow
>wrote: > If anyone has strong feelings for item-access over attribute-access,
>> please elaborate. I'm just not seeing it as that important and would >
>rather finish up the PEP as simply as possible.
On May 14, 2012, at 10:04 PM, Nick Coghlan wrote:
>As the subject line says, as Guido's delegate, I'm accepting
>Benjamin's PEP 415 with the current reference implementation.
I'm glad to see this PEP get accepted. I have just minor quibbles :).
Can you or Benjamin improve the title of the PEP?
On May 15, 2012, at 10:26 AM, Eric Snow wrote:
>At this point I'm pretty comfortable with where PEP 421 is at. Before
>asking for pronouncement, I'd like to know if anyone has any
>outstanding concerns that should be addressed first.
It looks great to me. If I were the PEP czar , I'd approve it
At what point should we cut over docs.python.org to point to the Python 3
documentation by default? Wouldn't this be an easy bit to flip in order to
promote Python 3 more better?
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev
On May 18, 2012, at 11:36 AM, Benjamin Peterson wrote:
>2012/5/18 Barry Warsaw :
>> At what point should we cut over docs.python.org to point to the Python 3
>> documentation by default? Wouldn't this be an easy bit to flip in order to
>> promote Python 3 more better?
On May 20, 2012, at 04:27 PM, Raymond Hettinger wrote:
>When there is more uptake of Python 3, it would be reasonable move.
How do we measure this, and what's the milestone for enough uptake to make
the switch?
Cheers,
-Barry
signature.asc
Description: PGP signature
___
On May 21, 2012, at 02:28 PM, Nick Coghlan wrote:
>Rather than a new subdomain, I'd prefer to see a discreet
>"documentation version" CSS widget, similar to that used in the Django
>docs (see https://docs.djangoproject.com/en/1.4/) that indicated the
>current displayed version and provided quick l
I've mentioned this in private to a few folks, with generally positive
feedback.
I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If
there are no objections in the next few days, I'll make it official.
Cheers,
-Barry
signature.asc
Description: PGP signature
__
Minor nit.
On May 22, 2012, at 04:43 PM, PJ Eby wrote:
>def declare_namespace(package_name):
> parent, dot, tail = package_name.rpartition('.')
> attr = '__path__'
> if dot:
>declare_namespace(parent)
> else:
>parent, attr = 'sys', 'path'
> with importlockconte
On May 25, 2012, at 06:07 AM, Nick Coghlan wrote:
>If it only started happening recently, suspicion would naturally fall on
>the hash randomisation security fix (as I assume a new version of Python
>would have been pushed for 10.04 with that update)
I do not think the hash randomization patch has
On May 25, 2012, at 10:31 AM, Brett Cannon wrote:
>Is documentation coming in a separate commit?
Yes. I've been reworking the import machinery documentation; it's a
work-in-progress on the pep-420 feature clone ('importdocs' branch). I made
some good progress and then got side-tracked, but I'm
On May 21, 2012, at 05:24 PM, Barry Warsaw wrote:
>I've mentioned this in private to a few folks, with generally positive
>feedback.
>
>I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If
>there are no objections in the next few days, I'll make
On May 17, 2012, at 07:19 AM, Eric Snow wrote:
>PEP 421 has reached a good place and I'd like to ask for pronouncement.
As the newly self-appointed PEP 421 czar, I hereby accept this PEP.
Eric, you've done a masterful job at balancing and addressing the input from
the Python development communit
On May 31, 2012, at 01:21 AM, Eric Snow wrote:
>The implementation for sys.implementation is going to use a new (but
>"private") type[1]. It's basically equivalent to the following:
>
>class namespace:
>def __init__(self, **kwargs):
>self.__dict__.update(kwargs)
>def __repr__(self
On May 31, 2012, at 10:31 PM, Nick Coghlan wrote:
>Personally, I suggest we just expose the new type as
>types.SimpleNamespace (implemented in Lib/types.py as "SimpleNamespace
>= type(sys.implementation)" and call it done.
Great idea, +1.
Eric, if you want to remove the special case for _names i
On Jun 01, 2012, at 11:49 PM, Nick Coghlan wrote:
>The long term goal here is that all the code in the standard library
>should be implementation independent - PyPy, Jython, IronPython, et al
>should be able to grab it and just run it. That means the
>implementation specific stuff needs to migrate
On Jun 01, 2012, at 03:22 PM, Mark Shannon wrote:
>I thought this list was for CPython, not other implementations ;)
This list serves a dual purpose. Its primary purpose is to discuss
development of Python-the-language. It's also where discussions about
CPython-the-implementation occur, but tha
On Jun 03, 2012, at 01:22 PM, Martin v. Löwis wrote:
>- Some people (Barry in particular) are in favor of timed releases.
> I don't know what the actual motivation for timed releases is, but
Timed releases in general can provide much better predictability for others
depending on those releases.
Thanks for the second set of eyes, Brett.
On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote:
>> +.. data:: implementation
>> +
>> + An object containing the information about the implementation of the
>> + currently running Python interpreter. Its attributes are the those
>>
>
>"the those" ->
On Jun 04, 2012, at 01:19 PM, Dirkjan Ochtman wrote:
>I recently opened issue14908. At work, I have to do a bunch of things
>with dates, times and timezones, and sometimes Unix timestamps are
>also involved (largely for easy compatibility with legacy APIs). I
>find the relative obscurity when conv
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
>Personally, I would really like not having to think about the time
>module at all, except if I wanted to go low-level (e.g. get a Unix
>timestamp from scratch).
+1
Oh and, practicality beats purity.
-Barry
___
On Jun 04, 2012, at 11:39 AM, Brett Cannon wrote:
>OK, then I would add a test to make sure this happens, like
>``self.assertEqual(sys.implementation.name, sys.implement.name.lower())``
>if you don't want to bother documenting it to make sure other VMs conform.
Good idea. Done.
-Barry
signatu
On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote:
>The second feature has its uses. If I want wake up at 7 AM every
>weekday, I don't want my alarm clock ask me whether I mean standard or
>daylight saving time, but if I attempt to set it to 1:30 AM on the day
>when 1:30 AM happens twice,
On Jun 06, 2012, at 05:55 PM, Ben Finney wrote:
>The PEP document currently says it targets “3.x”. I'll leave it in that
>state until we're more confident that the current work will be on track
>for a particular Python release.
>
>Do I need to do anything in particular to be explicit that PEP 3143
On Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote:
>1. Asking on python-dev is considered adequate. If an implementation
>wants to be consulted on changes, one or more of their developers
>*must* follow python-dev sufficiently closely that they don't miss
>cross-VM compatibility questions.
That's
On Jun 21, 2012, at 07:48 AM, Chris McDonough wrote:
>I don't know about Red Hat but both Ubuntu and Apple put all kinds of stuff
>on the default sys.path of the system Python of the box that's related to
>their software's concerns only. I don't understand why people accept this
>but get crazy ab
On Jun 21, 2012, at 08:51 AM, Chris McDonough wrote:
>The reason it's disappointing to see OS vendors mutating the default sys.path
>is because they put *very old versions of very common non-stdlib packages*
>(e.g. zope.interface, lxml) on sys.path by default. The path is tainted out
>of the box
On Jun 22, 2012, at 12:27 PM, Paul Moore wrote:
>And what I am trying to say is that no matter how much effort gets put
>into trying to make build from source easy, it'll pretty much always
>not be even remotely trivial on Windows.
It seems to me that a "Windows build service" is something the Py
2201 - 2300 of 2704 matches
Mail list logo