[issue1626300] 'Installing Python Modules' does not work for Windows
Chris Lambacher added the comment: I don't think that is the default state. You need to add .py to the PATHEXT environment variable: http://effbot.org/pyfaq/how-do-i-make-python-scripts-executable.htm Maybe Terry did this at some point? My windows box certainly does not have it and I have 2.6 and 2.7 installed. I don't have a 3.x install so I can't check if that is new in 3. -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue1626300> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1626300] 'Installing Python Modules' does not work for Windows
Chris Lambacher added the comment: > Now my concern is about packaging: In a typical Windows install, can people > run “pysetup3 spam”? The windows installer does not make any additions to the path so it is unlikely that "pysetup3 spam" will work. There is http://www.python.org/dev/peps/pep-0397/ which addresses running scripts in a multi-version windows environment but I don't think that will help in this case. If you are running more than 1 version of windows there is simple statement that tells you how to install and have the install go to the right interpreter. You are almost best to have a shortcut that gives you a command prompt with the PATH variable correctly set to the desired python instance. That does not help the 2.x crowd or anyone before 3.3 :/ -- ___ Python tracker <http://bugs.python.org/issue1626300> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1626300] 'Installing Python Modules' does not work for Windows
Chris Lambacher added the comment: > I am not sure of the difference between 'local script' and 'global command' local script is the setup.py (or for that matter any other script in an arbitrary place in the filesystem. Global command is referring to something installed in %PYTHONINSTALLDIR%\scripts i.e. it is an installed command. This one operates on a specific version instance of python. I for instance have c:\python26\scripts\easy_install.exe and c:\python27\script\easy_install.exe and each of those operates on their own particular version. Neither are in my path. The current state is that I have to either put one of the scripts directories in my path or run easy_install with the full path. My understanding is that pysetup is a replacement for easy_install that will come with 3.3. > I am not sure what 'or does the installer add .py?' could mean. The Windows > installer? 'Add' to what? I was referring .py being added to the PATHEXT evironment variable. I think it is safe to say that has not happened and is likely a bad idea. -- ___ Python tracker <http://bugs.python.org/issue1626300> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: Senthil: I think that would fundamentally make things worse. The HTML calendar apparently always provides a bytes type, but lets assume it provided you with unicode and we used sys.stdout.write on the output. Fundamentally you would get the same behavior as the patch provides since if you don't provide an encoding it uses sys.getdefaultencoding() which, IIUC is fundamentally what happens if you sys.stdout.write a unicode string. Ezio: I think it is highly unlikely that someone would be fiddling around with sys.stdout and then calling the main() function on calendar.main() (after setting up sys.args so that option parser gets the right parameters). -- ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: Senthil: I wasn't advocating the removal of the ability to specify encoding, only stating that avoiding the use of sys.stdout.buffer.write could only sensibly be done if we also removed the ability to specify an encoding (I can see how my wording might have been confusing). Earlier (msg122219) I said that we probably can't remove the encoding option because that would break backwards compatibility. FWIW, I think that the encoding parameter to the console program is probably sensible because there are no guarantees that the sys.getdefaultencoding() is actually set to the console encoding and I would guess that most people using the html option are not sending output to the console anyway. They are likely redirecting the output somewhere else because there is no "output this to a file" option. -- ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1156179] Calls from VBScript clobber passed args
Chris Lambacher added the comment: copied to pywin32 bug tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=3238774&group_id=78018&atid=551954 -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue1156179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6007] distutils tricks you into thinking you can build extensions with mingw
Chris Lambacher added the comment: I just compiled the zope.interface c speedups with MinGW on Python 2.7 and 2.6. There is a patch being tracked in the MinGW patch tracker <http://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&atid=302435> related to the localtime linking issue, but there is no indication that the patch was accepted. My experience with MinGW has been that it almost always works except where C++ is used or MinGW itself trips on a MSVCRT issue. Perhaps a note about that would be sufficient to close this bug? -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue6007> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6007] distutils tricks you into thinking you can build extensions with mingw
Chris Lambacher added the comment: I'm attaching a patch that includes a disclaimer about some extensions not being able to compile and mentioning some of Martin's specifics. I also reorganized the instructions to more directly reflect the current state. This puts the common instructions front and center and makes it more clear which instructions are directed at users of old python and MingGW versions. We might want to take those instructions out altogether given that the versions mentioned are pretty old (circa 2005). -- keywords: +patch Added file: http://bugs.python.org/file19714/updated_mingw_docs.patch ___ Python tracker <http://bugs.python.org/issue6007> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1043134] mimetypes.guess_extension('text/plain') == '.ksh' ???
Chris Lambacher added the comment: While I agree that getting .ksh is an unfortunate guess, I am not sure how you can guess in the face of many options (especially when the those options are parsed out of a mimetypes file or the windows registry). Perhaps there should be a "resonable_defaults" map that is checked first for very basic types where there are multiple extensions for a type? -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue1043134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6007] distutils tricks you into thinking you can build extensions with mingw
Chris Lambacher added the comment: Eric, This documentation is "Installing Python Modules" which is focused on Distutils, but presumably we would continue to want such a document and account for both Disutils and Disutils2 (once people start using it). I think my patch addresses the misleading content regarding the need to use pexports and dlltool and more directly instructs people that want to install the vast majority of current Python packages. If it is pertinent to update the docs for distutils2 I'll look at that as well but I think it is still useful to provide meaningful docs for what exists in distutils. -- ___ Python tracker <http://bugs.python.org/issue6007> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6799] mimetypes does not give cannonical extension for guess_extension with text/plain
Chris Lambacher added the comment: This is a dup of #1043134 -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue6799> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6434] buffer overflow in Zipfile when wrinting more than 2gig file
Chris Lambacher added the comment: This should be closed as a dup of #1182788 which the OP identified as being the same bug and which is now fixed due to the implementation. of ZIP64. -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue6434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3636] Managing dual 2.x and 3.0 installations on Windows
Chris Lambacher added the comment: This seems like a normal file association fight, no different than not being able to have both IE and Firefox associated with .html files. #2375 has been rejected, so I don't think it is a relevant superseder. I don't see how this is any different than having multiple 2.x installations and needing to pick the current one to work with. If 2.3 were the default and I tried to run a script with decorators I would end up with the same result. -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue3636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7858] os.utime(file, (0, 0, )) fails on on vfat, but doesn't fail immediately
Chris Lambacher added the comment: win_utime.patch does not apply cleanly on the py3k branch. Adapted, as in the attached win_utime_updated.patch, the solution does fix the problem. I have not added a test because I don't know how to deal with the fat32 requirement in order to cause failure, though I did test before and after applying the test on fat32 locally. -- nosy: +lambacck Added file: http://bugs.python.org/file19725/win_utime_updated.patch ___ Python tracker <http://bugs.python.org/issue7858> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue969718] BASECFLAGS are not passed to module build line
Chris Lambacher added the comment: I am attaching a preliminary patch to allow override of $(OPT). I am not sure this is sufficient, but am wary of breaking packages that depend on the existing behaviour. The logic indeed seems wrong, but maybe this is something that has to go in distutils2 rather than distutils. -- keywords: +patch Added file: http://bugs.python.org/file19750/distutils_opt_flag.patch ___ Python tracker <http://bugs.python.org/issue969718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1043134] mimetypes.guess_extension('text/plain') == '.ksh' ???
Chris Lambacher added the comment: Rafael, There is already a method which returns all the extensions. What is required is a flag (or separate dict) which provides a canonical extension. The questions is whether it is sufficient to rely on the default provided mimetypes for the default in the face of mimetypes read out of the mimetypes files or windows registry. I don't see a way to fix the bug, without also providing an API to "pick the winner" for those cases that are not provided in the default list. -- ___ Python tracker <http://bugs.python.org/issue1043134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: I have attached a patch that conditionally uses sys.stdout.buffer.write to output binary (encoded) data to stdout. -- nosy: +lambacck Added file: http://bugs.python.org/file19768/calendar_bytes_output.patch ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: I don't understand what you mean by "elides the line breaks in output". They are still there, you just don't see them as \n because print() is no longer implicitly converting the bytes to a string (which appears to actually result in a repr). -- ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: I am attaching a new patch which fixes the majority of the comments raised. 1. Any suggestions about how to test the output of the console program (the case that this bug affects) would be appreciated. 2. Agreed, included in the output for --help 3. Agreed, included in new patch 4. Okay. That is because of using write vs print. Changed to always use write 5. Doesn't seem to cause any issues on windows terminal. -- Added file: http://bugs.python.org/file19774/calendar_bytes_output_v2.patch ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: The test_pydoc method looks workable, but I'll need to come back to it later because I don't have any more time to work on it today. -- ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment: I don't think we *need* to have the encoding in the HTML calendar, but I doubt we could remove it at this point, deprecate maybe, but since I don't use the module I don't have a sense for how often the need for encoding comes up. The one thing that the encoding is doing in the HTML calendar is ensuring that Unicode characters that are not directly translatable in the target encoding are replaced with html character references (the "xmlcharrefreplace" option to the errors argument in the encode method). The encoding may be a holdover from Python 2x where the expected result was a string. The docs say HTMLCalendar was added in Python 2.5 at the same time that the Local versions were added. -- ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Chris Lambacher added the comment:
Sorry in advance for the long winded response.
Ron, have you looked at my patch?
The underlying issue is that the semantics for print() between Python 1 and 3.
print() does not accept a bytes type in Python 3. In Python 2 str was a "bytes"
type and so print happily sent encoded strings to stdout.
This presents an issue for both --type=html and the text version if an encoding
is asked for. Just using print() will result in repr being called on the byte
string and you get either an invalid HTML file or a text file with extra junk
in it (same junk in both).
If you ask for an encoding, you are going to get bytes. Changing it back into a
string to mask that effect does not actually fix things for you because once
you do print() you are back to a default encoding and therefore more broken
because you are not doing what the user asked for (which is a particular
encoding).
In order for:
return str(''.join(v).encode(encoding, "xmlcharrefreplace"),
encoding=encoding)
to solve the issue, you would also need to take away the ability for the user
to specify an encoding (at the command line and via the API). It's already a
string, why make it a byte and then a string again? If you don't want to deal
with encoding, then return a string and leave it up to the consumer of the API
to handle the desired encoding (and the "xmlcharrefreplace", maybe with a note
in the docs).
If you do want to deal with encoding (which I think we are stuck with), then
solve the real issue by not using print() (see my patch).
I think the only reason that my patch was not accepted, and why this is still
languishing is that I said I would provide tests and have not had time to do
so.
Please feel free to correct me if I am wrong about any of the above.
--
___
Python tracker
<http://bugs.python.org/issue10087>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue969718] BASECFLAGS are not passed to module build line
Chris Lambacher added the comment: I am not convinced that the minimal patch would work for my original issue. I wanted to be able to override the -march option which shows up in OPT on Fedora. I was cross-compiling to a target architecture that does not support the -march option so I would not be able to provide a different one as override. The proposed minimal patch would leave the OPT value and make it unchangeable because CFLAGS would pull out a value for OPT from the Makefile which shows as in my current Ubuntu system: OPT=-DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes BASECFLAGS= -fno-strict-aliasing CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) The debian-sysconfig-flags looks the most correct because it allows override at any point by emulating the CFLAGS = $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) logic. It still looks like it needs an override for EXTRA_CFLAGS and the logic for LD_SHARED looks wrong. In the Makefile LDSHARED is just: LDSHARED= $(CC) -shared -Wl,-O1 -Wl,-Bsymbolic-functions Why does LDSHARED need CFLAGS and CPPFLAGS? When provided as an override but not in the Makefile? Do we need to allow for this override in the case of overriding OPT, BASEFLAGS or EXTRA_CFLAGS? -- ___ Python tracker <http://bugs.python.org/issue969718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue969718] BASECFLAGS are not passed to module build line
Chris Lambacher added the comment: Antoine said: > I don't understand how you can cross-compile using the host Python > Makefile. Could you explain? The get_config_vars() function parses the host Makefile to get the values that we are discussing overriding. > EXTRA_CFLAGS is not defined in the Makefile so it would probably be > taken from the environment anyway (if my understand of Makefiles is > right). That seems to explain the name "EXTRA_CFLAGS", but I'm no > specialist of the jungle that have building systems become under Unix. You are correct, EXTRA_CFLAGS is not in the Makefile, but does provide us with an expected order of evaluation. i.e. Distutils is generating the equivalent command lines from the pieces and we should be respecting the Makefile order for consistency. Also, I don't know if there is a way to insert EXTRA_CFLAGS as an option to the ./configure script when Python is built such that it shows up in the resulting Makefile. If there is no way to get EXTRA_CFLAGS into the Makefile, then we should take it entirely out of the equation in the construction of the cflags var. Stephan Said: > Just out of curiosity: You are cross-compiling a C-extension? How can > you be sure that all values in pyconfig.h are correct? That is the whole point of this discussion, if you can sub out the build parameters, you can insert the path to the .h files for the embedded target before any host specific .h files. In order to build a C extension, you pretty much have to do it through Distutils and therefore the host python interpreter or else do a lot of extra work to get the right settings for each individual extension. See the following for some basic how-to info: http://whatschrisdoing.com/blog/2006/10/06/howto-cross-compile-python-25/ http://whatschrisdoing.com/blog/2009/10/16/cross-compiling-python-extensions/ -- ___ Python tracker <http://bugs.python.org/issue969718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3671] What's New in 2.6 - corrections
Chris Lambacher <[EMAIL PROTECTED]> added the comment: In rev66217, the itertools example for "With two iterables, 2N-tuples are returned." has a typo: itertools(product([1,2], [3,4], repeat=2) should be: itertools.product([1,2], [3,4], repeat=2) -- nosy: +lambacck ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18508] enum.Enum population of _value2member_map does not match fallback search
New submission from Chris Lambacher: When an Enum is being created, the _value2member_map class property is defined to speed lookup of Enum values later on. If the value does not exist then it falls back to a linear search through the _member_map.values() looking for member.value == value. This differs from population of the _value2member_map dictionary since population happens like this: enum_class._value2member_map[value] = enum_member This differs because "value" is the value of the property in the definition, not the _value property of enum_member. In most cases this does not matter, but for instances where a __new__ or __init__ is doing something funky with the values (like auto-numbering) then the _value2member_map dict won't have the right information. -- messages: 193379 nosy: lambacck priority: normal severity: normal status: open title: enum.Enum population of _value2member_map does not match fallback search type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue18508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18545] enum always runs member_type when use_args is True
New submission from Chris Lambacher: Starting at line 153 in enum.py there is: 153 if not use_args: 154 enum_member = __new__(enum_class) 155 original_value = value 156 else: 157 enum_member = __new__(enum_class, *args) 158 original_value = member_type(*args) 159 if not hasattr(enum_member, '_value_'): 160 enum_member._value_ = original_value When use_args is True, the member_type is always called with the arguments even if the return value from enum_member has a _value_ attr. If the __new__ function transforms the the *args then the call to member_type(*args) can fail even thought the value would not be used. I've attached a patch with a fix and a test to demonstrate the problem. The use case for the test in the attached patch is to populate Django ORM choices to a field. The first value in the tuple is the value used in the database (and as the Enum value) and the second value in the tuple is the label that Django shows in select boxes. -- files: enum_value_transform.patch keywords: patch messages: 193648 nosy: lambacck priority: normal severity: normal status: open title: enum always runs member_type when use_args is True type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file31028/enum_value_transform.patch ___ Python tracker <http://bugs.python.org/issue18545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18635] Enum sets _member_type_ to instantiated values but not the class
New submission from Chris Lambacher: It would be useful to set the discovered member_type to the Enum class and not just the instance. Attached is a patch to add _member_type_ to the enum_class. -- files: enum_member_type_on_class.patch keywords: patch messages: 194199 nosy: lambacck priority: normal severity: normal status: open title: Enum sets _member_type_ to instantiated values but not the class type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file31125/enum_member_type_on_class.patch ___ Python tracker <http://bugs.python.org/issue18635> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18635] Enum sets _member_type_ to instantiated values but not the class
Chris Lambacher added the comment: My use case is a generic mixin for Enums and a generic mixin for Django ORM fields that uses the Enums to generate choices. The Enum mixin has to call cls.__class__._get_mixins_(cls.__bases__) to get the member_type so that it can call the member_type.__new__ method (currently using this for int and str). I'm currently setting _member_type_ on the class if it doesn't already exist in the Enum class. The Django ORM field mixin has a to_python method where it is supposed to take input from the db/web and turn it into the python type (in this case an Enum). If we get a str from the web and we are going to an int, we need to run int on it. The generic way to do this in the mixin is to pass the value to _member_type_ as a function. I think I have all the bugs out of my implementation so I should be able to extract it out of my app and make it open source this week. -- ___ Python tracker <http://bugs.python.org/issue18635> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Chris Lambacher added the comment: I am really happy to see this as an option in the Windows installer. This has a potential to really reduce the support burden on training new Windows users to use Python and will really help normalize the experience for new users between Windows and POSIX platforms. Unfortunately, from what I can tell, this is OFF by default. I think that is a mistake. The default for something like this is really important because without new users being explicitly told to set it, new users will not. Most new Python users are just going to take the default values and still be confused by not being able to open the console and run python as in the instructions for various new user tutorials (i.e. web frameworks, scientific computing, etc). I understand the issue with installing multiple Python versions, but generally speaking people are going to want to install the latest version and have that be on their path. My sense is that there is a relative minority of Windows users that care about multiple versions of Python would not want their path to be updated. Unfortunately the ones who don't want their path updated are the ones that have driven the installer development at this point and will be most vocal in the Python community. I suggest a compromise which makes adding to the PATH default to ON if another Python version is not installed and/or on the PATH and default to OFF otherwise. It looks like you can use a condition table plus the feature table to check for Python in the path buy I am not exactly an expert with MSI. My quick check found: http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx which says you can do a search for an installed component and then set a property. This should then allow setting of the default state of the feature based on a condition. I really recommend that while we still have a chance to make a change that we think about the goal of this feature and whether making it disabled by default achieves those goals. -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Chris Lambacher added the comment: The reason for the conditional approach was to attempt to account for the "negative consequences" of adding enabling this by default. i.e. if you are already a Python developer and install a new version, it will be status quo, but if you are a new Python developer then you will be able to run instructions for packages that work perfectly fine on Windows but are maintained and documented by POSIX users and don't understand that the steps to make things work on Windows are different. I don't care one way or the other about the compromise position but I strongly believe that if someone is installing Python on Windows for the first time they should get a good experience without having to know of the existence of docs like: http://docs.python-guide.org/en/latest/starting/install/win/ This tweet https://twitter.com/#!/zedshaw/status/194853198006198272 is characteristic of the sentiment that non-Windows users have about training Windows users to develop with Python. At the PyCon web summit several people who have been doing training lately have said that their solution is to get windows users to run a Linux Virtual Machine because the Windows Python experience is so bad for new Windows developers. This is one relatively easy place where we can make that experience better. -- ___ Python tracker <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21671] CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required
New submission from Chris Lambacher: http://www.openssl.org/news/secadv_20140605.txt All client versions of OpenSSL are vulnerable so all Windows builds of Python are vulnerable to MITM attacks when connecting to vulnerable servers. -- components: Build, Windows messages: 219828 nosy: lambacck priority: normal severity: normal status: open title: CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19011] Enum should have a __getattr__ that makes all the instances available from an instance
New submission from Chris Lambacher: The use case for this is that when you are in a template and you want to use the Enum instances in a conditional, then you need to pass the Enum class to the template or start using someenumvariable.__class__.someenumvalue. Instead it would be useful to be able to do someenumvariable.someenumvalue. Implimenting as __getattr__ on enum class allows real attributes to take precedence and also allows for overriding of behaviour in child classes. -- components: Library (Lib) files: getattr_for_enum_class.patch keywords: patch messages: 197611 nosy: lambacck priority: normal severity: normal status: open title: Enum should have a __getattr__ that makes all the instances available from an instance versions: Python 3.4 Added file: http://bugs.python.org/file31745/getattr_for_enum_class.patch ___ Python tracker <http://bugs.python.org/issue19011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19011] Enum should have a __getattr__ that makes all the instances available from an instance
Chris Lambacher added the comment: You are not comparing the same thing. Normally when there is a class parameter, those are available from instances of the class. >>> class Test: ...pass ... >>> Test.this = Test() >>> Test.that = Test() >>> Test.this.that <__main__.Test instance at 0x7ff681bd3560> >>> >>> isinstance(Test.this, Test) True >>> from enum import IntEnum >>> class Color(IntEnum): ... red = 1 ... blue = 2 ... green = 3 ... >>> isinstance(Color.red, Color) True >>> -- ___ Python tracker <http://bugs.python.org/issue19011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19011] Enum should have a __getattr__ that makes all the instances available from an instance
Chris Lambacher added the comment: For what it's worth, I was confused by the inability to access the class members from the instance for like 3 or 4 weeks until I realized that the instances were not actually on the class and the implications of that for class attribute access. -- ___ Python tracker <http://bugs.python.org/issue19011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue969718] BASECFLAGS are not passed to module build line
Chris Lambacher added the comment: I am running into a problem related to this. I am attempting to cross compile extensions but Fedora includes -march in the OPT variable. Since there is no way to exclude the OPT values the build fails. It seems that forcing OPT to stay the same is a disservice generally speaking since as Marien said you potentially get extra conflicting flags (-O seems like a stand-out since that could mess with gdb). 2.6 and 3.1 say: if 'CFLAGS' in os.environ: cflags = opt + ' ' + os.environ['CFLAGS'] ldshared = ldshared + ' ' + os.environ['CFLAGS'] There is no ability to override opt. I'd be willing to put together a patch to allow opt to be overridden by an environment variable if I could get some support for this from a core maintainer. I am also open to other suggestions about how to get around this. I potentially have time to put into fixing this (or the more general cross compile issue). -- nosy: +lambacck ___ Python tracker <http://bugs.python.org/issue969718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
